Comments 22
Многие способы выглядят как ошибки в соответствующих API. Неужели Microsoft не планирует их исправлять? Или, быть может, существуют какие-то сторонние патчи, например, от производителей антивирусного ПО?
Просто обнаружить эксплуацию, конечно, хорошо, но это ведь постфактум. Там уже вредоносное ПО может успеть натворить дел.
Так вы KPI коллективу не поднимите, премии платят только за редизайн и фичи.
Да, Microsoft не планирует их исправлять, некоторые из ошибок перекочевали из Windows 7. Насчёт патчей от вендоров тоже сомневаюсь, некоторые из ошибок слишком сложны, чтобы исправлять их вместо Microsoft (а это нужно ещё и поддерживать такой код!).
Насчёт обнаружить постфактум, я бы добавил что если есть какая-то автоматизация реагирования - то можно защититься раньше чем UAC Bypass успел состояться. Детект написан так, чтобы зафиксировать атаку как можно раньше там где это возможно.
Ну есть нюанс, в том, что хоть и заявляется, что UAC не является security boundary, но периодически Microsoft что-то все-таки латает, причем в security патчах. Хотя иногда это просто видимость. Например в упомянутом IFileOperation поменяли набор флагов, что сломало готовые эксплоиты, но почти сразу было замечено и исправлено.
Все эти обходы UAC работают когда пользователь НЕ входит в группу "Администраторы"?
UAC в целом работает только в случаях когда пользователь входит в группу "Администраторы", соответственно и обходы тоже.
К UAC не относится окно запроса учетных данных при попытке выполнить с правами админа?
А вы можете уточнить что вы хотите узнать задавая этот вопрос?
могу только предположить, т.к. тоже такой вопрос крутился в голове, что смысл вопроса в том, что не легче ли внедрить базовую гигиеническую меру безопасности - не работать под админом, чем пытаться самому в организации из "подручных средств" делать такие детекты.
да, если под обычной учетной записью указанные в статье проблемы не существуют, то не очень понятно зачем создавать какие-то проверки.
Потому что атаку используют, ну а если используют значит есть причина. Сам я так же думаю что проще просто вывести пользователя из группы администраторов, но если пользователь на домашнем ПК, то такого вопроса не стоит.
на домашнем ПК тоже можно использовать учетную запись с обычным уровнем прав + иметь админскую для запуска от ее имени ПО, когда это требуется.
Проявляются ли указанные в статье проблемы в случае использования учетной записи с обычным уровнем прав?
обход uac и повышение привелегий в системе идут рука об руку. главная проблема uac при постоянной работе под администратором - человек. со временем он просто начинает всегда нажимать "да"
Некоторые методы прям step-by-step инструкции))) сразу возникает желание опробовать и написать какой нибудь скриптик под это.
UAC Bypass и вариации на тему детектирования, Часть 2