# Форум на русском языке  > Разное  > Оффтоп  >  Методы обхода UAC

## XP user

Сегодня я был у одной ученицы. Там надо было - уже угадали - удалить зловреды на Висте. Ну вот. Что я там заметил?
Когда нажимаете *Ctrl+Alt+Del* - появится окно UAC (Управление учётными записями пользователей) с предупреждением ('Если вы запустили...' и т.д.), нажимаете 'ОК' и будет Диспетчер Задач.
Но когда нажимаете *Ctrl+Shift+Esc* - сразу же появится Диспетчер Задач без всякого предупреждения.

Хотел спросить у тех, у которых Виста c включённым UAC - вы это тоже заметили? Существуют ли ещё какие-либо комбинации в обходе UAC?

Paul

----------

Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:

----------


## Vadim Sterkin

*p2u*
Я бы не стал это рассматривать в контексте обхода UAC  :Smiley:  

Ctrl+Shift+Esc вызывает диспетчер задач. Это сочетание клавиш всегда было встроенной функцией NT систем для вызова диспетчера. Поскольку доступ к диспетчеру для обычных пользователей не ограничен, UAC его не контролирует никак. Для "убийства" процесса прав пользователя может быть недостаточно, но это уже другой вопрос.

Ctrl+Alt+Del вызывает "окно безопасности". В XP оно выглядело так

В Vista - изменилось

Если посмотреть на список задач в окне, то какие-то из них, видимо, контролируется UAC (сходу не могу сказать, какие именно). Отсюда и запрос. 

В XP поведение Ctrl+Alt+Del также зависит от того, включены экран приветствия и быстрое переключение пользователей или нет. Если включены, то сразу вызывался диспетчер задач. Возможно, что в Vista то же самое. Надо проверить  :Smiley:

----------


## XP user

> *p2u*
> Я бы не стал это рассматривать в контексте обхода UAC  
> 
> Ctrl+Shift+Esc вызывает диспетчер задач. 
> 
> Ctrl+Alt+Del вызывает "окно безопасности".


Факт остаётся - Ctrl+Alt+Del дало предупреждение (никакого окна безопасности я не видел - сразу же UAC был), а Ctrl+Shift+Esc дало сразу же Диспетчер задач без предупреждения. 

Я не могу это НЕ рассматрывать как обход одного и того же действия. Это для меня по ощущению похоже на кнопку Esc для обхода 'защиты' пароля в Win98, или кнопку Shift для обхода запрета автозапуска.

Может быть разные версии Висты по разному реагируют? Или при Ctrl+Alt+Del запускается служба, а при Ctrl+Shift+Esc просто программа? Естественно мне не до этого было там это подробно изучать...

Paul

----------


## ananas

При нажатии Ctrl+Shift+Esс из под пользователя Диспетчер задач на Висте запускается и при включенном Контроле учетных записей (UAC) без запроса на подтверждение.

----------


## XP user

> от имени админа. Но если это нажатие сделано из учетки пользователя, то он не доступен. Диспетчер запущен, значек в трее есть, а окна нет. Надо выйти из учетки пользователя и зайти админом, чтобы им воспользоваться. У меня на виста хоум премиум так.


Дело в том, что там надо было лечить систему; я был вынужден работать в учётке админа для того, чтобы избегать излишних алертов. Там именно я заметил разницу между двумя вариантами...

Paul

----------


## ananas

*p2u*, да, я понял из Вашего рассказа.

----------


## Vadim Sterkin

> Факт остаётся - Ctrl+Alt+Del дало предупреждение (никакого окна безопасности я не видел - сразу же UAC был), а Ctrl+Shift+Esc дало сразу же Диспетчер задач без предупреждения.


"Окно безопасности" я взял в кавычки, потому что я не знаю точно, как это называется в русской ОС. В англ. - Security Dialog Window - это то, что изображено на скриншотax в моем предыдущем посте. Вы его видите *после* запроса UAC. Опять же, я никогда не интересовался такими тонкостями UAC, но если очень интересно, могу попробовать выяснить у продакт-группы, почему запрос UAC появляется при нажатии этого сочетания клавиш. Мое предположение о том, что это обсусловлено действиями, которые доступны в "окне безопасности", остается в силе. Я посмотрел в политиках - ряд этих действий можно ими контролировать.

,




> Я не могу это НЕ рассматрывать как обход одного и того же действия. Это для меня по ощущению похоже на кнопку Esc для обхода 'защиты' пароля в Win98, или кнопку Shift для обхода запрета автозапуска.


У вас неверная предпосылка. Вы считаете, что эти две комбинации клавиш несут одну и ту же нагрузку, поэтому вас удивляет, что одно сочетание вызывает запрос, а другое - нет. Как я сказал выше, для вызова диспетчера задач используется Ctrl+Shift+Esc. А для вызова "окна безопасности" - Ctrl+Alt+Del. У меня на работе нажатие этой комбинации вызывает окно Novell Netware, в котором также есть возможность вызова диспетчера 



Многие пользователи считают, что для вызова диспетчера надо использовать Ctrl+Alt+Del. Да, он вызывается в ХР этим сочетанием, если включен экран приветствия и работает быстрое переключение, что является стандартными настройками ОС. Но это поведение нужно рассматривать как исключение, а не как правило.

В Vista, кстати, уже нет классического логона, поэтому Ctrl+Alt+Del в любом случае будет вызывать "окно безопасности", и выключение возможности быстрого переключения пользователей ничего не изменяет (я проверил). Поэтому если вам нужен диспетчер, жмите Ctrl+Shift+Esc или щелкайте пр. кн. мыши на панели задач и выбирайте соотв. пункт из меню. Так быстрее, чем через доп. окно. 




> Может быть разные версии Висты по разному реагируют? Или при Ctrl+Alt+Del запускается служба, а при Ctrl+Shift+Esc просто программа? Естественно мне не до этого было там это подробно изучать...


Поведение не зависит от редакции ОС.

----------


## XP user

@ *Vadim Sterkin* 

Я думаю, что причина в следующем:
Ctrl+Alt+Del = на самом деле hardware interrupt (аппаратное прерывание), команда, которую придумали в IBM. Это, естественно, более серьёзный процесс, чем просто вызов Диспетчера Задач.

Paul

----------


## NRA

> и работает быстрое переключение


ничего подобного, на ХР достаточно "экрана приветствия".



> Ctrl+Alt+Del = на самом деле hardware interrupt[


суть не в названии, а в том, что что-то вроде обычного sendkey может через hotkey[s] управлять машиной (скинуть комп в ждущий, завершить задание и т.д.)

Надо будет попробовать на работе на ViSTA через vba или js "взломать" UAC  :Wink:

----------


## Vadim Sterkin

> ничего подобного, на ХР достаточно "экрана приветствия".


Это связанные понятия. У меня в любом случае нет XP под рукой, так что могу только дать ссылку на доки При нажатии сочетания клавиш CTRL+ALT+DEL для открытия параметров безопасности Windows вместо этого открывается диспетчер задач



> Снимите флажок Использовать страницу приветствия.
> <...>
> Примечание Параметр Быстрое переключение пользователей будет отключен вместе с экраном приветствия.


*Добавлено через 12 минут*




> @ *Vadim Sterkin* 
> 
> Я думаю, что причина в следующем:
> Ctrl+Alt+Del = на самом деле hardware interrupt (аппаратное прерывание), команда, которую придумали в IBM. Это, естественно, более серьёзный процесс, чем просто вызов Диспетчера Задач.
> 
> Paul


Не знаю насчет hardware interrupt, но только процессу winlogon доверено отслеживание нажатия этой комбинации и вызов окна. Наверное, у Руссиновича что-то есть на эту тему в Wininternals. Поэтому для диспетчера есть отдельная комбинация.

----------


## XP user

> Не знаю насчет hardware interrupt, но только процессу winlogon доверено отслеживание нажатия этой комбинации и вызов окна. Наверное, у Руссиновича что-то есть на эту тему в Wininternals. Поэтому для диспетчера есть отдельная комбинация.


Ctrl-Alt-Del видимо всё-таки комбинация на уровне железа - я помню из рассказов Руссиновича, что она не может быть перехвачена прикладными программами и что она в NT была задумана как способ защиты  от программ-шпионов при входе в систему.

Paul

----------


## Vadim Sterkin

Процитирую книгу тогда (сорри, нет русской)




> secure attention sequence (SAS)
> A keystroke combination that when entered notifies Winlogon of a user logon request.





> *How SAS Is Implemented*
> 
> The SAS is secure because no application can intercept the Ctrl+Alt+Delete keystroke combination or prevent Winlogon from receiving it. Winlogon uses a documented Windows API, RegisterHotKey, to reserve the Ctrl+Alt+Delete key combination so that whenever the Windows input system sees the combination, it sends a special message to a window that Winlogon creates to receive such notifications. The keystrokes that map to a registered hot key are otherwise not sent to any process other than the one that registered it, and only the thread that registered a hot key can unregister it (using the UnregisterHotKey API), so a Trojan horse application cannot deregister Winlogon's ownership of the SAS.
> 
> A Windows function, SetWindowsHook, enables an application to install a hook procedure that's invoked every time a keystroke is pressed, even before hot keys are processed, and it allows the hook to squash keystrokes. However, the Windows hot key processing code contains a special case for Ctrl+Alt+Delete that disables hooks so that the keystroke sequence can't be intercepted. In addition, if the interactive desktop is locked, only hot keys owned by Winlogon are processed.

----------


## XP user

> Процитирую книгу тогда (сорри, нет русской)


Короче, я думал, что там всё хитрее. Эксплуатировать можно значит. Спасибо.  :Smiley: 

Paul

----------


## Vadim Sterkin

> Короче, я думал, что там всё хитрее. Эксплуатировать можно значит. Спасибо.


Поздравляю! Вы только что обнаружили уязвимость в коде Windows, имевшуюся там лет 10, наверное  :Smiley:  Честно говоря, на меня такие многозначительные заявления не производят впечатления, равно как и такие 



> Надо будет попробовать на работе на ViSTA через vba или js "взломать" UAC


Я понимаю, что тематика данного форума к взлому отношения не имеет, да и меня не очень интересует тема взлома сама по себе. Так что я оставлю обсуждение этого вопроса экспертам по инфобезу и ядру Windows  :Smiley:

----------


## XP user

@ *Vadim Sterkin* 

Дело, естественно не в желании взлома (меня это мало привлекает), а в том, насколько вероятность, что некоторые зверушки будут пытаться обходить UAC. У меня подозрение, что уже обходят и пытаюсь найти для этого объяснения.  :Smiley: 

Paul

----------


## Vadim Sterkin

Наверное, чтобы лучше понять, как обходят, нужно хорошо представлять, как UAC работает (те, кто научился обходить, должны это представлять очень хорошо). 

С точки зрения пользователя, работает он слишком сложно (или надоедливо), посему многие отключают (вот и самый легкий метод обхода - внедрить то, чем пользоваться неудобно  :Smiley: ). А из объяснений экспертов, пожалуй, лучшая статья опять же у Руссиновича - Управление учетными записями пользователей Windows Vista: взгляд изнутри.

----------


## XP user

> Наверное, чтобы лучше понять, как обходят, нужно хорошо представлять, как UAC работает (те, кто научился обходить, должны это представлять очень хорошо).


В том-то и дело, что наши враги (дети от 13-19, прошу заметить!) себе это гораздо лучше представляют, чем те, которые называют себя экспертами и учат нас тому, 'как надо'.  :Smiley: 




> А из объяснений экспертов, пожалуй, лучшая статья опять же у Руссиновича - Управление учетными записями пользователей Windows Vista: взгляд изнутри.


Эта статья мне хорошо известна. Любопытно, однако, что на атаки Rutkowksa и других на то, как работает UAC на самом деле получили от Руссиновича следующий ответ:



> [SNIP]UAC не следует рассматривать в качестве механизма безопасности. Скорее это способ указать разработчикам на написание более безопасных приложений[SNIP]


Не зря Майкрософт купила Руссиновича - в прошлом он бы реагировал совсем по другому...  :Roll Eyes (Sarcastic): 

Paul

----------


## NRA

> в прошлом он бы реагировал совсем по другому


Люди меняются - кто в лучшую сторону, а кто - в другую. В общем - стареют.

ПО же должно (теоретически) только улучшаться, но вместо UAC я бы предпочёл изоляцию (=разделение) процессов, когда процессы "не видят" друг-друга и могут изменять/создавать только "свои" файлы/реестр в своей папке/ветке.
А в связке с нормальной реализацией UAC их нужно было бы дольше пробивать: кулхацкерам пришлось бы найти 2 дыры (а они есть), которые бы совпали в брешь.

----------


## Vadim Sterkin

> В том-то и дело, что наши враги (дети от 13-19, прошу заметить!) себе это гораздо лучше представляют, чем те, которые называют себя экспертами и учат нас тому, 'как надо'.


Не знаю, откуда вы берете такие цифры, но в целом я могу согласиться, что "враги" достаточно молоды  :Smiley: 



> Не зря Майкрософт купила Руссиновича - в прошлом он бы реагировал совсем по другому...


Я тоже думаю, что не зря, но немного в другом контексте. Поскольку тема в оффтопе, поясню подробнее  :Smiley:  Критиков и хакеров всегда хватает. А вот грамотных специалистов такого уровня, как Руссинович (он ведь помимо наличия знаний умеет еще и излагать хорошо), не так уж много. Конечно, работая в МС, он уже не может позволить себе говорить некоторые вещи или должен балансировать на грани, но надо смотреть и на положительную сторону - такие люди могут повлиять на развитие Windows в положительную сторону (как бы скептически вы не относились к возможности такого развития событий  :Wink: ). Замечу, что я сказал "могут", а не "способны". Могут повлиять, а могут и не повлиять - смотря, как их использовать. Марк - желанный гость на всех крупных конференциях, так что я даже не знаю, есть ли у него время на работу "внутри" компании или его используют в основном как лицо. И, конечно, используют - насколько я понял из его рассказа о Technet Springboard, он с подозрением относится к маркетинговым проектам (видимо, потому что они размывают его образ), так что он изначально не хотел "вписываться" и долго выяснял, что же это будет в итоге. Кстати, он будет в Москве на Платформе-2009 в начале декабря.

Что же касается приведенной вами цитаты, то я не поленился отыскать ее в оригинале. Собственно говоря, я знал, что в ней не так, но хотел найти источник. Марк говорил не о механизмах безопасности, а о границах безопасности - это несколько разные вещи, конецптуально разные, а не просто игра слов. Прошу прощения за длинную цитату на английском, но не хочу вырезать из контекста; к тому же, он говорит еще и о балансе удобства и безопасности (выделение полужирным - мое).




> However, let’s be clear that no matter how difficult to pull off, the mere possibility of such a breach of a sandbox wall implies that ILs, in and of themselves, do not define security boundaries.  *What’s a security boundary? It’s a wall through which code and data can’t pass without the authorization of a security policy.* User accounts running in separate sessions are separated by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user. If for some reason it was possible to bypass security policy, it would mean that there was a security bug in Windows (or third-party code that allows it). 
> *It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard.* Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use.  
> Not requiring a user to type Ctrl+Alt+Delete to verify that the credential dialog UAC presents for an OTS elevation is one example of security balanced against usability, but there are others, like the ones I describe in my TechEd/ITForum talk User Account Control Internals and Impact on Malware (Jim’s post describes some of the ways you can enhance security while tipping the balance against ease of use, like configuring Windows to require Ctrl+Al+Delete for the credential dialog). For instance, having your elevated AAM processes run in the same account as your other processes gives you the convenience of allowing your elevated processes access to your account’s code and data, but at the same time allows your non-elevated processes to modify that same code and data to potentially cause an elevated process to load arbitrary code.   
> *Because elevations and ILs don’t define a security boundary, potential avenues of attack* *, regardless of ease or scope, are not security bugs*. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, *why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.*


UAC - первый шаг к отходу от общепринятой практики работы админом в Windows, которую сама МС и насадила, в принципе. Можно сказать и "первый блин", но надо смотреть и на положительные моменты... Насколько это маленький шаг можно судить хотя бы по тому, что при установке ОС создаваемая учетная запись все так же является административной. Но идея в том, что со временем это изменится. За одно поколение ОС свою же философию переписать невозможно. 




> но вместо UAC я бы предпочёл изоляцию (=разделение) процессов, когда процессы "не видят" друг-друга и могут изменять/создавать только "свои" файлы/реестр в своей папке/ветке.


А как же им тогда взаимодействовать с друг другом? Да и проблемы легитимного доступа к файлам/реестру будут немалые... Впрочем, я не программист, мне трудно судить о перспективности такого направления  :Smiley:

----------


## NRA

*Vadim Sterkin*, Вы процитировали



> User accounts running in separate sessions are *separated* by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user


Это как раз относится к тому что я говорил, но термин <*сессия*> - более глобально чем <процесс> или <приложение>. Вот и всё.



> А как же им тогда взаимодействовать с друг другом?


А вот от этом и нужно было заботится разработчикам: либо делать "платформу", либо закрытый целевой (например по PID) буфер, либо ещё что-то.
Самый простой вариант сохранить нужные данные, а другой программой открыть - видимы только данные.



> Да и проблемы легитимного доступа к файлам/реестру будут немалые


Причина? А я считаю, что совсем наоборот - каждая программа будет работать в своём workspace и сможет изменять только свои данные.
Конечно, из этой структуры немного выпадают демоны - драйвера и службы, но я считаю что и они не должны обслуживать "всех подряд", а только тех, кто имеет на это разрешение.
С уважением,

----------


## ananas

Спасибо всем, почитал. Одно место особенно понравилось, что, раз нет границ безопасности, следовательно, эти границы невозможно нарушить.
Только эндюзеру разве от этого легче?

Имхо, при разных мнениях очевидно, что проблема все-таки есть. Осталось надеяться, что и решение будет. Т.е. будем надеяться на лучшее.  :Smiley:

----------

Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:

----------


## Vadim Sterkin

> Причина? А я считаю, что совсем наоборот - каждая программа будет работать в своём workspace и сможет изменять только свои данные.
> Конечно, из этой структуры немного выпадают демоны - драйвера и службы, но я считаю что и они не должны обслуживать "всех подряд", а только тех, кто имеет на это разрешение.


Возможно, я неверно интерпретировал фразу 


> когда процессы "не видят" друг-друга и могут изменять/создавать только "свои" файлы/реестр в своей папке/ветке.


Примеры. 

Вы решили с помощью Блокнота изменить файл настроек программы Х. Исходя из вашей концепции, Блокнот не имеет права изменять настройки программы Х.

Вы решили изменить параметры реестра в разделе программы Х с помощью программы Y. Программа Y не может это сделать, т.к. это не ее раздел.

----------


## ananas

А по-моему это все о том же.
Должны быть определены доверенные приложения, наделенные правами вносить доверенные изменения.
Должна быть определена доверенная область, из которой доверенные приложения выполняют доверенные действия.
И проблема таже.
Как защитить доверенные приложения от подмены недоверенными.
Как защитить доверенную область от проникновения в нее недоверенных приложений под видом доверенных.

----------


## 55LEO55

Ну

*Добавлено через 59 секунд*

В мене в вісті коли я нажимаю Ctrl+alt+Delete не відображаєтся Диспечер задач що робити?!?!?!

*Добавлено через 35 секунд*

Допоможіть будь ласка  :Sad:

----------


## ALEX(XX)

> Ну
> 
> *Добавлено через 59 секунд*
> 
> В мене в вісті коли я нажимаю Ctrl+alt+Delete не відображаєтся Диспечер задач що робити?!?!?!
> 
> *Добавлено через 35 секунд*
> 
> Допоможіть будь ласка


Виконайте будь-ласка ці *правила* Але вони російською. Я сподіваюся, що російську Ви розумієте.

----------


## 55LEO55

Добре зараз попробую  :Sad:

----------

