Проблема небезопасной загрузки динамических библиотек вообще характерна для продуктов Microsoft. Она стала причиной уязвимостей MS10-087, MS10-093, MS10-094, MS10-095, MS10-096, MS10-097, MS11-001, MS11-003, MS11-015, MS11-016, MS11-017, MS11-023, MS11-025, KB2533623, MS11-055, MS11-059, MS11-071, MS11-073, MS11-075, MS11-076, MS11-085, MS11-094, MS11-099, MS12-012, MS12-014, MS12-022, MS12-039, MS12-046, MS12-074, MS14-023.

Ответственность за обеспечение безопасности подключения библиотек в первую очередь на разработчиках. Например, при указании при вызове функции LoadLibraryEx() ключа LOAD_LIBRARY_SEARCH_SYSTEM32 поиск библиотеки начинается с system32 (странно, почему Microsoft не мог просто использовать это в скайпе?).

Но что-то в силах сделать и администраторы.

Во-первых, это ключ SafeDllSearchMode (HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerSafeDllSearchMode), который немного меняет порядок поиска библиотек:

1. Директория, из которой запущно приложение

2. Системная директория

3. Директория Winodws

4. Текущая директория

5. Директории из переменной окружения PATH

Если отключить SafeDllSearchMode, порядок будет такой:

1. Директория, из которой запущно приложение

2. Текущая директория

3. Системная директория

4. Директория Winodws

5. Директории из переменной окружения PATH

Особо интересны два момента:

– Если библиотека с таким именем уже загружена в память, то будет использоваться этот образ

– Если библиотека присутствует в KnownDlls, то она будет загружаться из стандартного пути

На последнем моменте надо остановиться подробнее. Известные библиотеки перечислены в узле реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs и по умолчанию загружаются ТОЛЬКО из системных директорий. Путь их поиска можно задать ключами HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs:DllDirectory и HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs:DllDirectory32.

Поэтому, в общем то, вчерашнюю проблему со скайпом можно решить путем добавления библиотеки в KnownDlls.

Источник: https://t.me/informhardening

Недавно анонсирована уязвимость повышения прав в Windows через Skype.

Уязвимость примечательна тем, что Microsoft сказал “слишком сложно” и “исправим в следующей версии”.

Для обновления Skype использует не общие механизмы Windows Update, а собственное приложение “%ProgramFiles%SkypeUpdaterUpdater.exe”, которое запускается с правами SYSTEM.

Если обнаружено доступное обновление Updater.exe распаковывает его в “%SystemRoot%TempSKY<abcd>.tmp” и запускает команду “%SystemRoot%TempSKY<abcd>.tmp” /QUIET. Это приложение загружает дополнительные библиотеки, в частности UXTheme.dll, и ищет их сначала в папке запуска (что в общем то обычное дело) %SystemRoot%Temp.

Соответственно, при наличии у пользователя доступа к папке %SystemRoot%Temp он может подменить библиотеку кодом, который выполнится с правами SYSTEM.

Папка %SystemRoot%Temp используется множеством софта, так что нельзя просто взять и ограничить к ней доступ.

Можно было бы удалить Updater.exe, но тогда скайп не будет обновляться. Что ж, давайте сделаем так: скопируем UXTheme.dll из %SystemRoot%system32 в %SystemRoot%Temp и запретим к ней доступ на изменение и запись – скайп будет загружать ее, а подменить ее хакеру с правами рядового пользователя не удастся.

источник: https://t.me/informhardening

Cisco включает по умолчанию функцию Proxy ARP на интерфейсах третьего уровня своего оборудования. Вы можете о ней даже не знать, а она есть…

Proxy ARP позволяет интерфейсу отвечать на “чужие” ARP-запросы своим маком. Это происходит, когда выполняются следующие условия (все сразу):

• – целевой IP-адрес ARP-запроса находится в IP-подсети, отличной от IP-подсети, в которой ARP-запрос получен
• – маршрутизатор имеет один или несколько маршрутов к целевому IP-адресу ARP-запроса
• – маршруты к целевому IP-адресу ARP-запроса указывают на исходящий интерфейс, отличный от интерфейса, на который ARP-запрос был получен

Это может быть нужно, когда:

1. Используется NAT с пулом адресов, не входящих в ту же сеть, что и адрес интерфейса
2. Используется странная фрагментация сети, когда клиенты считают, что их сеть шире, чем прописано на интерфейсе. Например, если клиенты не поддерживают произвольную длину маски.

Proxy ARP в некоторой степени расширяет широковещательный домен, увеличивая область применения сетевых атак на локальный сегмент. Поэтому его рекомендуется отключать. Ну и избыточная функциональность – к чему она?

При настройке NAT (первый случай применения Proxy ARP) рекомендуется назначать интерфейсу секондари адрес из пула NAT, это включит еще и Gratuitous ARP.

Второй случай использования Proxy ARP весьма специфический и очень редкий.

Так что выключаем) Можно выключить глобально:

 (config)# ip arp proxy disable 

Или на каждом интерфейсе:

(config-if)# no ip proxy-arp 

На ASA:

 (config)# sysopt noproxyarp <interface_name> 

Источник: https://t.me/informhardening