Contents of this directory is archived and no longer updated.

Update: этот пост периодически обновляется.


Вот и пришло время сделать сводный пост по своим исследованиям Software Restriction Policies. Здесь я опубликую ссылки на предыдущие материалы, посвящённые этой действительно интересной технологии. К сожалению это скорее всего будет означать завершение срывов покровов в этом направлении. Безусловно, технологии не стоят на месте, а постоянно развиваются, поэтому очень долго топтаться на одном месте не стоит. Но это совсем не означает, что SRP стал реликвией, музейным экспонатом и просто утилем. SRP до сих пор имеет и какое-то время будет иметь важное значение в обеспечении безопасности ОС Windows, поскольку теперь политики SRP поставляются во все домашние редакции Windows 7. А так же будет неотъемлемой частью обеспечения безопасности уже активно используемых систем начиная с Windows XP.

И, собственно, сам список.

Опубликованная в журнале «Системный администратор» статья даст представление о том, что такое SRP, поведает о ключевых особенностях этих политик и может выступать в качестве теоретической базы для работы с SRP.

Первая часть исправлений к журнальной статье, в которой рассказывается про особенности использования прямых «/» и обратных «\» слешей в правилах пути, а так же про обход политик через системные папки, которые разрешены пользователям для записи.

В этой части рассказаны методы обхода SRP на примере запуска CHM файлов и потенциальной возможности запуска некоторого кода с использованием файлов с расширением SCF. Плюс даны некоторые рекомендации по организации правил для типовой рабочей станции и косметические настройки обработки групповых политик в отношении SRP.

Очередной обзор нескольких способов обхода политик SRP путём подмены системных переменных окружения, использованием в обработке расширений LNK и подстановкой нелегитимных доверенных издателей (цифровых подписей). Так же приведён потенциальный полувандалистский метод атаки на SRP путём генерации зашедуленного задания в ожидании, когда политика будет отключена в профилактических целях.

В этом посте детально рассказано о непростом порядке сортировки и применения множества правил SRP. Используя этот материал вы научитесь разрешать конфликты в правилах и упростит планирование правил SRP.

И ещё один метод обхода политик SRP через шорткаты и обнаружение второй достаточно серьёзной уязвимости SRP, которую закрыть достаточно сложно.

содержит официальное заявления сотрудника техподдежки Microsoft — Rahul Denkanikota. В результате двухмесячного общения с техподдержкой мне лично была предложена замена для mshta.exe, которая уже лишена недостатка оригинального файла. Однако, данное решение не планируется выпускать в массы по причине очень большой специфики. В остальных же случаях, если это возможно, следует полностью отказаться от mshta.exe и заблокировать его на уровне правил SRP.

В этом посте опубликовано решение, которое позволяет защитить SRP от подстановки ложных сертификатов цифровых подписей. В целом, с некоторыми оговорками, после данного поста репутация SRP вновь восстановлена до уровня «надёжно».

Краткая статья, содержащая сравнение возможностей SRP и его последователя, AppLocker.

В этой части рассказывается о проблемах и их решении при внедрении SRP в 64-разрядных ситемах, терминальных серверах и небольшой рассказ об отличиях правил SRP в Windows Vista и более новых систем по сравнению с pre-Vista системами (Windows XP/Server 2003).

Коллекторский пост, содержащий ссылки на статьи в knowledge base (KB), связанные с теми или иными проблемами работы с SRP.

Вот и всё… :pop:


Share this article:

Comments:

shss.wordpress.com

>Вот и всё… а, вот и не все... как тебе нравиться такой элегантный способ обхода SRP: C:\Documents and Settings\user>runas /trustlevel:"Unrestricted" C:\temp\bad_program.exe вместо Unrestricted надо ставить то слово, которым называется уровень доступа SRP в ОС, на которой запускается эта команда. Так, например, для русской версии - эта команда будет выглядеть так: C:\Documents and Settings\user>runas /trustlevel:"Неограниченный" C:\temp\bad_program.exe Другие способы обхода, ссыкли на которые дал Kazun, можно посмотреть здесь: http://www.it-blojek.ru/forum/index.php?topic=114.msg1358#msg1358 http://www.it-blojek.ru/forum/index.php?topic=114.msg1424#msg1424

Vadims Podāns

Во-первых, на сколько я понял, это работает только в XP. В 2003 и выше уже нет. И можно запретить политикой RunAs по хешу.

shss.wordpress.com

>И можно запретить политикой RunAs по хешу можно, никто не спорит. Я, собственно про то, что стоит об этом вставить упоминание в одной из твоих статей. Остальные способы обхода SRP поделились на 2 части (простую и сложную), но для осуществления любой из этих частей требутся запустить скрипт (макрос) в какой-либо прикладной программе, в которой SRP, естественно бессильна что-либо контролировать. 1) в простом случае макрос передаст управление на dll, которая может быть подоложена в папку с документом, содержащем макрос. Бороться с этим можно, включив контроль dll в SRP 2)в сложном - скрипт пропатчит память системы и отключит SRP. Бороться с этим можно только недопущением запуска неизвестных скриптов (макросов) в 3d soft'е

Vadims Podāns

Ну если с первым бороться можно, то со вторым, имхо, никак. Всё-таки, SRP, в отличии от аплокера работает в user space, поэтому не представляется возможным закрыть эту дыру. Опять же, не стоит очень сильно скатываться в такие редкие сценарии, потому что SRP не закроет 100% атак. Но 99% вполне может, чего нам вполне хватает. 100% вы в любом случае не получите.

Михаил

Пора обновить этот пост.

Vadims Podāns

Что именно надо обновлять?

Comments are closed.