Подавляющее большинство современных windows приложений использует стандартные элементы управления для собственных интерфейсов. Большое число приложений из этой группы реализует механизмы разграничения прав пользователей, выраженные в пользовательском интерфейсе при помощи соответствующих элементов управления. Это всем нам знакомые элементы выбора (radio button), флаги (check box), выпадающие списки (drop down menu) и некоторые другие.
Идея защиты в рассмотренных выше приложениях очень проста, если пользователь работающий с приложением имеет достаточно прав, то элементы интерфейса являются активными и пользователь может с ними взаимодействовать. В случае же если у пользователя таких прав недостаточно, то данные элементы становятся неактивными (визуально выражено, как более тусклая окраска или серый фон). Идея элементарна, но в ней существует один очень серьёзный недостаток.
Использование стандартных элементов управления не только позволяет очень быстро реализовывать пользовательские интерфейсы, но и влечёт за собой наследование всего стандартного функционала, являющегося частью операционной системы. Так неактивность какого-либо элемента является всего-лишь флагом стиля этого элемента. Справка по WinAPI говорит что состояние окна неактивно является следствием выставления флага WS_DISABLED, тут же в справке говорится что для удаления этого стиля необходимо использовать функцию EnableWindow. В качестве параметров эта функция принимает хендл окна или элемента управления (являющийся глобальным) и логическое значение отвечающее, собственно, за включение/отключение элемента. Таким образом мы видим, что функция носит глобальный характер и не выполняет никаких хакерских действий. Такой механизм был создан ещё во времена Windows 2000 и работает по сей день. Тут надо сделать оговорку, что выполнять такие действия пользователь может только с запущенными от его имени процессами, но и с этими процессами можно выполнить множество вредоносных действий.
Таким образом любой пользователь при помощи нехитрых утилит (например являющихся частью Visual Studio или InqSoft Window Scanner - kickme.to/inqsoft) пользователь может активировать функциональность, защищённую только посредством дезактивации элемента управления. В этом случае если при проектировании и создании приложения данная особенность не учитывалась, то у злонамеренного пользователя появляется возможность выполнить некоторые привилегированные действия. Какие – зависит уже от конкретного приложения.
Так например непривелигированный пользовательй службы терминалов Windows Sever 2003 может активировать неактивный по умолчанию для него переключатель “Отображать процессы всех пользователей” в Диспетчере Задач и успешно просмотреть процессы других пользователей (завершить правда он их не сможет, по причине дополнительных проверок прав при попытке закрытия процесса). Данный пример не показывает всей глубины проблемы, но вот следующий пример более нагляден.
Ещё одним примером уязвимой архитектуры может служить Kaspersky Anti-Virus 6.0 for Windows Workstation, входящий в состав Kaspersky EnterpriseSpace Security. С помощью политики устанавливаемой централизованно возможно запретить пользователям самостоятельно останавливать защиту ПК, но при этом такой запрет осуществляется только посредством деактивации флага отвечающего за работу защиты. При помощи указанных выше утилит, совершенно любой пользователь может сделать элемент управления активным и отключить антивирусную защиту своего ПК, а это уже намного более серьёзная брешь в безопасности, по сравнению с просмотром списка чужих процессов.
Надеюсь в ближайшем будущем производители ПО займутся исправлением этого архитектурного недостатка.
Копипаст отсюда: https://trukhanov.wordpress.com/2010/11/24/enablewindow-attack/
<<<<Надеюсь в ближайшем будущем производители ПО займутся исправлением этого архитектурного недостатка.
Это не архитектурный недостаток, а некомпетентность администратора, который не защищает интерфейс паролем или вовсе его не отключает.
а вы много видели приложений которые защищают свой интерфейс паролем? или же приложения которые вообще отключают свой интерфейс? не считая антивирусного
В статье говорят об атаке на Кaspersky Anti-Virus 6.0, а не о методике 10 летней давности.
В Кaspersky Anti-Virus 6.0 есть функции предотвращения таких атак (о них я написал выше), поэтому я не считаю это архитектурным недостатком.
хм… а вроде как раз о методике рассказывается, а Кaspersky Anti-Virus 6.0 является лишь достаточно ярким примером, который затрагивает достаточно широкую аудиторию.
Цитирую: «Ещё одним примером уязвимой архитектуры может служить Kaspersky Anti-Virus 6.0 for Windows Workstation».
А по поводу дополнительной защиты, да, ее начал включать после того, как научился выгружать антивирусные продукты с помощью повышения привилегий через at (хотя сейчас уже выполнение этой команды достаточно часто запрещено политиками). И действительно дополнительную защиту крайне рекомендуется использовать везде где есть возможность, правда многие этому противиться, так как зачастую при усилении безопасности уменьшается комфортность
Простите действительно о методике. Просто меня задала методика тестирования (хотя никого отношения не имею к антивирусным кампаниям) и выводы.
=)