Удаленный ipc что это

Скрытые административные и общие сетевые ресурсы в Windows XP/2000 C$, ADMIN$, FAX$, IPC$, PRINT$

Многие пользователи локальных сетей часто не подозревают что их диски являются сетевыми ресурсами к которым можно подключится, упоминаются как скрытые административные и общие ресурсы C$, ADMIN$, FAX$, IPC$, PRINT$. Их нужно отключить если они вам не нужны!

Виды общих сетевых ресурсов в Windows XP/200

По умолчанию в Windows XP/2000 могут быть созданы следующие скрытые административные общие ресурсы:

1. корневые разделы или тома C$ (D$, E$, F$ и т.д.);
2. корневой каталог операционной системы ADMIN$;
3. общий ресурс FAX$;
4. общий ресурс IPC$;
5. общий ресурс PRINT$.

Для корневых разделов и томов в качестве имени общего ресурса используется имя диска, к которому добавляется символ «$». Например, для доступа к дискам C и D будут созданы общие ресурсы C$ и D$ .

Корневой каталог операционной системы ( %SYSTEMROOT% ) – это каталог, в котом установлена операционная система Windows. Общий ресурс ADMIN$ предоставляет администраторам доступ к этой папке по сети.

Общий ресурс FAX$ используется пользователями для отправки факсов. В этой папке кэшируются файлы и титульные страницы, находящиеся на файловом сервере.

Общий ресурс IPC$ используется при организации временных подключений, создаваемых приложениями для обмена данными с помощью именованных каналов. Как правило, он применяется для удаленного администрирования серверов в сети.

Общий ресурс PRINT$ используется для удаленного администрирования принтеров.

Если удалить скрытые административные ресурсы, созданные операционной системой (например, ADMIN$ или C$), то после перезагрузки компьютера или перезапуска службы «Сервер» они будут созданы повторно. Если удалить скрытые административные ресурсы, созданные пользователями, то после перезагрузки компьютера они повторно созданы не будут. Microsoft Windows XP Home Edition не создает скрытые административные общие ресурсы.

Подключение к общим сетевым ресурсам в Windows XP/2000

Для подключения к скрытым административным и общим сетевым ресурсам можно использовать стандартную команду Windows XP/2000 net use :

Команда net use используется для подключения и отключения от сетевых ресурсов и для вывода сведений о текущих подключениях к таким ресурсам. Если сетевой ресурс является текущим диском или его использует какое-либо работающее приложение, отключиться от такого ресурса невозможно.

Ниже приводится пример использования команды net use для подключения к стандартному общему ресурсу C$ , компьютера под управлением Windows 2000, с полным именем Pro2000 , расположенного в локальной сети:

/>Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Команда net use выполнена успешно под именем пользователя Администратор и пустым паролем! В большинстве случаев после установки Windows, пароль на учетную запись с именем Администратор, создаваемую по умолчанию, забывают или просто не хотят ставить, а бывает так, что во время установки создавалась другая административная учетная запись, а учетная запись с именем Администратор, созданная по умолчанию, осталась без внимания!

Далее мы можем делать с этим ресурсом практически всё что нашей душе будет угодно, C$ ассоциирован с какой либо свободной буквой диска, в нашем случае это q:

После подключения ресурса C$ и его ассоциации с буквой диска, ресурс C$ будет доступен в вашем проводнике и с ним можно будет работать так, как с обычным локальным диском, ну, а дальше всё будет зависеть от ваших способностей и фантазии.

ВНИМАНИЕ. Общие ресурсы будут доступны только в том случае когда включена/запущена служба «Сервер», а если вы не собираетесь расшаривать свои ресурсы, то лучше её не просто остановить, а отключить совсем. Служба «Сервер» — Обеспечивает поддержку общий доступ к файлам, принтерам и именованным каналам для данного компьютера через сетевое подключение. Если служба остановлена, такие функции не удастся выполнить. Если данная служба неразрешена, не удастся запустить любые явно зависимые службы.

Приведённый выше пример наглядно демонстрирует уязвимость неприкрытых сетевых ресурсов и учетной записи Администратор, созданную по умолчанию с пустым паролем! Во избежание образования подобных щелей и как результат регулярной переустановки Windows с последующим преданием анафеме Билла Гейтса нужно просто изначально прикрывать, так сказать, все щели и дыры.

Отключение/удаление общих сетевых ресурсов

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

Для отключения административных и общих сетевых ресурсов (C$, ADMIN$, FAX$, IPC$, PRINT$) в Windows XP/2000 нужно:

/>Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

ПРИМЕЧАНИЕ! В Windows 2000 параметр AutoShareWks добавлять не требуется.

После перезагрузки ПК будут удалены все общие сетевые ресурсы, за исключением одного IPC$ , его нельзя удалить:

Особый общий ресурс IPC$

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

Особый общий ресурс IPC$ обязателен для работы службы серверов и не может быть удален. Просмотреть список текущих общих сетевых ресурсов можно командой net share

Повторимся, что воизбежание образования щелей в общих сетевых ресурсах и как результат регулярной переустановки Windows с последующим преданием анафеме Билла Гейтса нужно просто изначально прикрывать, так сказать, все щели и дыры.

Русские Блоги

Изучите AIDL и IPC из привязки удаленного обслуживания

По умолчанию, независимо от того, сколько Activity, Service или других компонентов имеет приложение, все они работают в одном процессе, но мы можем организовать запуск службы в новом процессе, но как должны взаимодействовать разные процессы? Что нужно делать, когда объекты нужно передавать между разными процессами? AIDL (язык определения интерфейса Android) является ключом к решению этой проблемы.

Использование AIDL не сложно, но это громоздко, и легко делать ошибки, если вы не будете осторожны. К счастью, Android Dev GuideDesigning a Remote Interface Using AIDLОбъяснение этой проблемы очень подробное, в сочетании с примером, приведенным в Привязке удаленного обслуживания в Android APIDemo, это дает разработчикам очень хорошую помощь. Ниже приведены заметки, которые я собрал из двух, и стремлюсь к правде, но возможности ограничены, и ошибки неизбежны. Пожалуйста, придерживайтесь своего мнения. Эта статья только для справки и не может быть доверенным.

1. Использование AIDL для реализации IPC

Столкнувшись с проблемой, общая ситуация должна быть кратко изложена, этап должен быть обобщен, и этапы должны быть разграничены. Есть четыре основных этапа, которые заключаются в следующем:

Создать .aidl файл Определите метод и поле в этом файле Добавить файл .aidl в makefile Если вы используете Eclipse, ADT поможет вам управлять Реализуйте методы интерфейса Компилятор AIDL сгенерирует интерфейс, написанный на Java, в соответствии с интерфейсом. Этот интерфейс имеет абстрактный внутренний класс с именемStub, Вы должны создать класс, наследовать от него и реализовать метод, объявленный в файле .adil. Выставь интерфейс клиенту Если служба создана, она должна быть унаследована отServiceИ перезагрузитеService.onBind()Вернуть экземпляр класса, который реализует интерфейс

Эти четыре шага представлены в разделе «Привязка к удаленному сервису», которые отдельно описаны ниже. Привязка к удаленным службам содержит два файла .java и три файла .aidl. Физическая структура относительно проста, но логическая структура не так проста. В следующем примере используется диаграмма классов для демонстрации взаимосвязи.

Remote Service Binding

1. Создайте .aidl файл

AIDL имеет простой синтаксис для объявления интерфейса. Методы в нем получают параметры и возвращаемые значения, но типы параметров и возвращаемых значений ограничены. Некоторые типы требуют импорта, а другие нет.

Типы данных, поддерживаемые AIDL, делятся на четыре категории, первая категория — это основные типы в языке программирования Java, вторая категория — это String, List, Map и CharSequence, третья категория — это интерфейс, созданный другим AIDL, и четвертая категория реализована. Пользовательский класс протокола Parcelable.
Среди них, кроме первой категории, остальные три категории требуют особой осторожности при использовании.

При использовании второй категории сначала необходимо понять, что эти категории не требуют импорта и являются встроенными. Во-вторых, при использовании контейнерных классов List и Map следует отметить, что элементы должны быть типов данных, поддерживаемых AIDL. List может поддерживать универсальные шаблоны, но Map не поддерживает его. В то же время конкретный класс, отвечающий за получение на другом конце, должен ЗдесьArrayListиHashMap。

При использовании третьей и четвертой категорий необходимо обратить внимание на то, что все они должны быть импортированы, но когда первая передается, ссылка передается, а последняя является значением.

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

Привязка удаленной службы включает три файла .aidl, а именно IRemoteService.aidl, IRemoteServiceCallback.aidl, ISecondary.aidl, с помощью которых вы можете увидеть, как использовать первый и третий типы типов данных, редко, не вижу К использованию второго и четвертого типов данных я не увидел метки направления.

2. Реализуйте интерфейс

AIDL создает файл интерфейса для вас, имя файла совпадает с именем файла .aidl. Если вы используете плагин Eclipse, AIDL будет автоматически запускаться во время процесса сборки, если вы не используете плагин, вам сначала нужно использовать AIDL.

Сгенерированный интерфейс будет содержать абстрактный внутренний класс Stub, который объявляет все методы в файле .aidl. Stub также определяет некоторые методы справки, наиболее часто используемыеasInterface(), Который получаетIBinderВ качестве параметра и возвращает экземпляр интерфейса, используемый для вызова метода IPC.

Чтобы реализовать интерфейс, вам нужно унаследовать Stub и реализовать его методы.RemoteServiceиRemoteServiceBindingСвязанные коды можно найти.

Эта ссылка является главным приоритетом. Есть два момента, которые требуют особого внимания: во-первых, все сгенерированные исключения не будут отправлены вызывающей стороне, а во-вторых, синхронизация вызова IPC означает, что услуга IPC занимает много времени. После завершения это вызовет ANR, такие операции должны быть помещены в отдельный поток.

3. Откройте интерфейс для клиента

Dulele не так хорош, как Lele, и сервис должен быть обнародован. Чтобы достичь этой цели, нужно его создать.ServiceПодкласс и реализоватьService.onBind(Intent), Этот метод возвращает экземпляр класса, который реализует интерфейс. ПросмотревRemoteServiceС первого взгляда

Среди них mBinder и mSecondaryBinder реализованы соответственноIRemoteServiceиISecondary Экземпляр класса интерфейса.

4. Используйте Parcelables для передачи значений

Как упоминалось ранее, Remote Servcie Binding не использует четвертый тип данных в качестве параметра. Это недостаток примера. Чтобы преобразовать класс в четвертый тип, необходимо выполнить следующие шаги:

1. ВведенныйParcelableинтерфейс
2. реализацияwriteToParcel(Parcel out)
3. Добавить статическое поле, его реализацияParcelable.Creatorинтерфейс
4. Создайте файл .aidl, чтобы объявить свой класс посылок

вDesigning a Remote Interface Using AIDLВ категорииRectЭто хороший пример, который компенсирует отсутствие привязки удаленного сервиса.

Во-вторых, вызовите метод IPC

Все доступно, только Дунфэн должен, и МПК готов, только чтобы позвонить. В Remote Service Binding RemoteServiceBinding является вызывающей стороной IPC,

Поскольку вы хотите использовать интерфейс, сначала объявите переменную типа interface,

реализацияServiceConnectionВonServiceConnected(ComponentName className, IBinder service)Завершено в серединеmServiceиmSecondaryServiceНазначение.

Security FAQ

IPC$, или Inter Process Communication, представляет собой специальный административный ресурс, предназначенный для создания именованных каналов. Посредством последних компьютеры обмениваются в сети различной служебной информацией. IPC$ также служит для дистанционного управления сервером.

Для того, чтобы решить, отключать данный ресурс или нет, необходимо учесть следующее:
1. Если это рабочая станция, которой нужно управлять удаленно, лучше не отключать.
2. Если рабочая станция не требует удаленного администрирования, можно и отключить.
3. Если это сервер, то отключать и вовсе не стоит, т.к. к нему будет невозможно достучаться по сети.
Отключается IPC$ через CMD командой «net share ipc$ /delete» (после перезагрузки данный ресурс все равно сам включается, поэтому можно написать соответствующий bat-файл и поместить его в автозагрузку).

Нужно ли отключать службу удаленного доступа к реестру? Если да, то как это сделать?

Remote Registry (удаленный реестр) позволяет удаленным пользователям изменять параметры реестра на текущем компьютере. Во избежание потенциальных рисков рекомендуется отключать данную службу. Делается это одним из следующих способов:
1. Остановка службы в панели управления (Пуск/Настройка/Панель Управления/Производительность и обслуживание/Администрирование Службы.
2. Через реестр внесением значения 4: HKLM\SYSTEM\CurrentControlSet\Services\RemoteRegistry параметр Start = 4.

При отключении данной службы возможны некоторые побочные эффекты, связанные с административными оснастками управления (например, может некорректно работать оснастка RRAS, хотя сама служба будет работать нормально).

Известно, что многие вирусы подменяют системные файлы своими. Как определить эту подмену?

Для того, чтобы быть всегда в курсе подобных «проделок», необходимо включить функцию уведомления о защите файлов. Делается это путем внесения в реестр по адресу: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SystemFileProtection параметра типа DWORD ShowPopups, равного 1.

Давно хотел узнать, следует ли отключать службы криптографии (Cryptographic Services) и защищенное хранилище ProtectedStorage?

Итак, служба криптографии. Функции: данная служба предоставляет три службы управления: службу баз данных каталога, которая проверяет цифровые подписи файлов Windows, службу защищенного корня, которая добавляет и удаляет сертификаты доверенного корня центра сертификации с этого компьютера, и службу ключей, которая позволяет подавать заявки на сертификаты с этого компьютера. Говоря простым языком, данная служба проверяет подписи файлов Windows. Служба как воздух необходима для обновления Windows как в ручном, так и в автоматическом режимах, а также для инсталляции различных SP и DirectX 9.0. Windows Media Player и некоторые .NET-приложения могут требовать эту службу для работы некоторых функций. Учитывая вышесказанное и при условии, что ваш ПК не находится в локальной сети или Интернет, службу можно отключить.

Вторая служба — защищенное хранилище, она же Protected Storage — обеспечивает защищенное хранение секретных данных — таких, как закрытые ключи — для предотвращения несанкционированного доступа служб, процессов или пользователей. Она также сохраняет введенные локальные пароли. Данная служба может пригодиться при работе с зашифрованными данными и ключами от различных программ и источников. Если вы не работаете с защищенными протоколами, можно отключить.

Я часто люблю экспериментировать с Windows. При попытке подмены файла системы своим через некоторое время мой файл заменяется системным. В чем дело?

Все дело во встроенной защите системных файлов. Даже приложения, разработанные корпорацией «Майкрософт», не могут заменять защищенные этой системой файлы на их старые версии. Для того, чтобы избежать «самоподмены», следует отключить защиту файлов, которую представляет служба System File Protection. SFP регистрирует попытку подменить системный файл и далее восстанавливает его исходную копию. Итак, для того, чтобы отключить SFP:

Для Windows 2000 без Service Pack 2 (SP2) в раздел реестра HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon добавляем параметр DWORD SFCDisable со значением FFFFFF9D.

Для Windows 2000 с Service Pack 2 (SP2) открываем файл по адресу %\systemroot%\system32\sfc.dll в любом шестнадцатеричном редакторе (например, HEDIT), переходим на смещение 00006211 (6211 hex) и изменяем байты 8BC6 на 9090, после чего в реестре устанавливаем параметр SFCDisable равным FFFFFF9D.

Для Windows XP без SP1 в файле по адресу %\systemroot%\system32\sfc_os.dll со смещением 0000E2B8 (E2B8 hex) изменяем байты 8BC6 на 9090. В реестре устанавливаем параметр SFCDisable равным FFFFFF9D.

Для Windows XP с SP1 в этом же файле sfc_os.dll по адресу 0000E3BB (E3BB hex) изменяем байты 8BC6 на 9090. В реестре устанавливаем значение параметра SFCDisable равным FFFFFF9D.

Важно помнить, что для параметра SFCDisable существуют следующие возможные значения:
0 — включить WFP/SFC.
1 — отключить WFP/SFC до следующей перезагрузки ПК, во время которой будет выдано приглашение снова включить защиту файлов.
2 — отключить WFP/SFC до следующей перезагрузки.
4 — включить WFP/SFC, отключить выдачу всех всплывающих сообщений о работе этой службы.
FFFFFF9D — полностью выключить WFP/SFC.

Расскажите, пожалуйста, в двух словах, что такое сетевой спуффинг?

Фактически спуффинг — это подмена. В данном случае имеется в виду IP-спуффинг т.е. подмена IP. Подмена, при которой злонамеренный
пользователь, воспользовавшись чужим IP-адресом, находящимся в пределах доверенной зоны IP-адресов, или авторизованным внешним адресом, выдает себя за объект, которому можно доверять.

Как сделать так, чтобы определенный пользователь в системе не смог запустить определенную программу?

Для ограничения запускаемых программ необходимо открыть раздел HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVerson\Policies\Explorer и создать там ключ RestrictRun типа DWORD со значением 0х00000001. Затем тут же надо создать подраздел с аналогичным именем RestrictRun и в нем перечислить список разрешенных на запуск программ для текущего пользователя. Записи в этом подразделе нумеруются начиная с 1 и содержат строки с путями и именами приложений (файлы должны иметь расширение, например, Word.exe, Excel.exe. ).

Через некоторое время после запуска Windows XP появляется окно с надписью: «. вызвано NT AUTORITY\SYSTEM. остановка службы Удаленный вызов процедур (RPC). » Что это такое, и как с этим бороться?

Судя по окну, скорее всего, ваш компьютер инфицирован червем MSBLAST или одной из его модификаций. Для того, чтобы подцепить подобную заразу, достаточно выйти в сеть Интернет с непропатченной системой и открытыми портами 135, 139 и 445. Чтобы окончательно убедиться, что это MSBLAST, необходимо проверить следующее:

1. Наличие записи «windows auto update»=»ms-blast.exe» в разделе Run системного реестра Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

2. Присутствие файла MSBLAST.EXE, TEEKIDS.EXE или PENIS32.EXE в папке Windows\System32\.

Для того, чтобы удалить это зло, необходимо:
1. Убить процесс MSBLAST.EXE, TEEKIDS.EXE или PENIS32.EXE в диспетчере задач.
2. Удалить в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run запись на запуск червя.
3. Перегрузить ПК.
4. «Долечить» систему утилитами, которые можно скачать по адресу: сайт
5. Установить патч: www.microsoft.com/security/security_bulletins/ms03-026.asp

Олег Бойцев (Cyber Tank), Cyber_Tank@mail.ru

Компьютерная газета. Статья была опубликована в номере 06 за 2007 год в рубрике безопасность

RPC и способы его мониторинга

Мы — команда исследователей‑аналитиков киберугроз в компании R‑Vision. Одной из наших задач является исследование возможных альтернативных и дополнительных источников событий для более точного детектирования атак.

И сегодня мы рассмотрим тему мониторинга RPC (Remote Procedure Call, удаленный вызов процедур), а также разберем возможные варианты логирования Microsoft Remote Procedure Call (MS‑RPC), связанного с актуальными и популярными на сегодняшний день атаками.

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

Что такое RPC?

Remote Procedure Call или «удаленный вызов процедур» представляет собой технологию межпроцессного взаимодействия IPC. Она позволяет программам вызывать функции и процедуры удаленно таким образом, как‑будто они представлены локально. В среде Windows используется проприетарный протокол от Microsoft — MS‑RPC, который является производным от технологии DCE/RPC (Distributed Computing Environment/ Remote Procedure Calls). Для упрощения понимания мы будем называть MS‑RPC просто RPC.

Службы RPC используются во множестве процессов в операционных системах Windows. Например, с их помощью можно удалённо изменять значения в реестре, создавать новые задачи и сервисы. На вызовах RPC построена значимая часть работы Active Directory: функции аутентификации в домене, репликация данных и многие другие вещи — список грандиозно большой.

В виду того, что RPC используется в Windows практически во всех процессах, по понятным причинам она является предметом особого интереса для атакующих. В тоже время RPC фигурирует в большом количестве популярных и опасных атак. К ним относится PetitPotam, с чьей помощью можно произвести атаку типа Relay на машинный аккаунт контроллера домена. Еще одна атака — DCSync, позволяющая скомпрометировать всех пользователей в домене при наличии учетной записи с высокими привилегиями. Кроме того, в арсенале атакующих есть еще и фреймворк Impacket, который может задействовать RPC для отправки вредоносных команд на удаленный сервер.

Все это говорит нам о важности понимания механизмов работы RPC, а также о необходимости её мониторинга.

Механизмы работы RPC

Изучение механизмов работы RPC мы начнем с краткого разбора сетевого трафика, поскольку протокол RPC в первую очередь является сетевым. На рисунке 1 мы видим подключение к удалённой машине: оно начинается с Bind запроса (выделен красным), после которого фигурирует второй Bind запрос (выделен синим). Первый используется для подключения к службе Endpoint Mapper (EPM), про него мы поговорим дальше. Второй инициирует подключение к самому RPC интерфейсу. После прохождения аутентификации устанавливается сессия, а уже дальше осуществляется вызов нужной функции и возвращение результата.

Рисунок 1. Вызов функции на удалённой машине с помощью RPC

Эволюция, конечно, могла бы остановиться здесь, если бы для RPC применялись только протоколы TCP и UDP, но в Microsoft пошли немного дальше и применяют так называемую последовательность из протоколов. К ней мы вернемся позднее, а сейчас рассмотрим, что такое EPM.

Endpoint Mapper

Одним из важных механизмов взаимодействия с RPC сервисами является служба Endpoint Mapper (EPM), расположенная на стороне сервера. Её главная задача помочь определить параметры дальнейшего подключения к нужному сервису для клиента. Сам EPM, как это ни странно, является таким же RPC сервисом, использующим для транспорта порты TCP/135 или TCP/593 (RPC over HTTP).

Рисунок 2. Служба *RPC Endpoint Mapper на устройстве

EPM‑cервис расположен на каждой Windows машине и содержит базу зарегистрированных RPC интерфейсов. За каждый из интерфейсов чаще всего отвечает свой исполняемый файл или динамически подгружаемая библиотека (DLL). Посмотреть список всех доступных интерфейсов можно с помощью утилиты rcpdump.py из упомянутого нами ранее фреймворка Impacket.

На рисунке 3 приведен пример вывода по одному из доступных интерфейсов.

Рисунок 3. Пример интерфейса, выводимый командой rpcdump.py

Здесь мы можем увидеть:

Название интерфейса: Netlogon Remote Protocol;

Библиотеку провайдера, отвечающего за нужные нам функции: netlogon.dll;

Уникальный идентификатор интерфейса: UUID;

Список точек подключения к данному интерфейсу, которые записываются в формате:

Отметим в приведенном выше интерфейсе два протокола:

ncacn_np — отражает подключение по именованному каналу Named Pipes (NPs). В связи с этим у него вместо порта указан путь.

Может возникнуть вполне резонный вопрос: всегда ли нужно обращаться к EPM? Нет, не всегда, так как существуют статические точки подключения, остающиеся неизменными. К ним, например, относится NPs \pipe\lsass .

Можно также посмотреть на RPC интерфейсы процессов не только снаружи, но и «изнутри». Они выглядят примерно так.

Что дальше?

После того как клиент определил куда он будет дальше подключаться, в процесс вступает сериализация данных. Если клиентом является Windows система, то эту работу будет выполнять компонент NDR (Network Data Representation). Он также отвечает за десериализацию данных со стороны RPC сервера. После чего данные попадают в качестве аргументов функции и другой информации для вызова этой самой функции в DLL библиотеку, ответственную за определённый RPC функционал. На финальном этапе функция выполняется, а её вывод передаётся обратно в RPC для отправки клиенту.

Протоколы в RPC

Разобравшись как работает RPC, подробнее изучим протоколы, которые активно эксплуатируются в интерфейсах RPC и, следовательно, доступны атакующему. И первым мы рассмотрим протокол Named Pipes (NPs).

Named Pipes

Данный протокол следует принципам передачи данных через чтение и запись: используя NPs можно записывать, а также сразу читать наименование и аргументы функций. Более того, это даже можно делать одновременно. NPs проще всего представлять в виде файлов: в Windows взаимодействие с ними происходит с помощью функций CreateFile, ReadFile, WriteFile, что в некоторой степени намекает нам на схожесть этих технологий. NPs выполняет роль интеграционного слоя между RPC и другими служебными компонентами.

Со стороны клиента NPs можно представить как точки подключения для выполнения какого‑то конкретного функционала. Например, точка подключения \pipe\svcctl направлена на управление службами на конечном устройстве. Однако Microsoft не всегда следует такому разделению. Так, при подключении к \pipe\lsass можно вызвать функции EFS сервиса, если передать корректный UUID при выполнении bind запроса.
На стороне сервера, на который происходит обращение, выполняется импорт библиотеки, отвечающий за EFS ( C:\Windows\System32\efslsaext.dll ) в процесс lsass . Стоит отметить, что у EFS существует свой собственный интерфейс \pipe\efsr .
Также EFS функционал может быть вызван с помощью других точек, например через samr или lsarpc , за каждым из которых стоит процесс lsass . Это в свою очередь наталкивает на мысль о некоторой «универсальности» процессов — интерфейсов, так как каждый процесс может импортировать нужную библиотеку и существует возможность вызывать функции любых других сервисов.

Перейдем к следующему протоколу — SMB.

Если отойти немного от протокола RPC и посмотреть на NPs отдельно, мы обнаружим, что NPs может вполне заменить RPC, так как первый исполняет функции удаленно даже без второго. Для этих целей он использует протокол SMB (Server Message Block). При этом фактически SMB нужен только для доступа к служебной директории IPC$ , аббревиатура которой расшифровывается как Interprocess Communication. Через эту «папку» можно читать, записывать, но только NPs, что вполне в духе SMB, и вызывать таким образом удаленные функции.

До этого мы говорили про протоколы, которые используются в удаленным вызове, но есть и локальный вариант RPC — протокол LRPC, у которого существует две трактовки: Local RPC или Lightweight RPC. Этот протокол предназначен только для локальных вызовов. Конечно, при использовании подключений по NPs или RPC на адрес localhost эффект будет тот же. Более того, некоторые программы так и делают, но для локальных вызовов LRPC работает куда быстрее и он удобнее в использовании. В выводе rpcdump.py мы его видели «зашифрованным» под ncalrpc . При этом LRPC работает поверх ALPC — еще одного протокола, о котором будет сказано чуть позже.
Но сначала про LPC.

LPC (Local Procedure Call) — также отвечает за механизм общения процессов в одной и той же системе. Данный протокол является недокументированным и используется (использовался) только внутри самой Microsoft. БОльшую часть информации об этом протоколе мы можем узнать исходя из работ реверс специалистов. Сторонний софт использует его не напрямую, а взаимодействует через документированный LRPC.

А теперь вернемся к ALPC.

LPC — это все же устаревшая технология и в явном виде уже не используется. На смену ей пришел ALPC (Advanced Local Procedure Call), являющийся асинхронным и также недокументированным протоколом. Работает он по принципу клиент‑серверной модели. В качестве сервера выступает процесс, принимающий соединения на определённый порт. Порт для подключения открывается с помощью функции NtAlpcCreatePort . Любой процесс имеет возможность подключиться к этому порту в качестве клиента, используя функцию NtAlpcConnectPort . Один «процесс‑сервер» может взаимодействовать сразу с несколькими клиентами одновременно.

Рассмотрим последний протокол, который фигурирует в RPC — DCOM, чья аббревиатура расшифровывается как Distributed COM. Фактически эта технология вызова COM‑интерфейсов удалённо. Тут нет больших отличий со стороны трафика, но есть различия в механизме вызова удаленных функций. DCOM не вызывает функции напрямую, а сначала инициализирует COM‑объект, функционал которого будет использовать. Концептуально это похоже на NPs с их разделением функционала на отдельные именованные каналы. Если рассматривать алгоритм общения клиента и сервера, то здесь не так много отличий от «чистого» RPC, но есть два исключения — вызов функций ISystemActivator и IDispatch.

Для вызова функции определённого COM объекта, такой объект сначала нужно вызвать, чтобы затем он «запустился»: загрузился в оперативную память и был доступен для работы. В локальном мире этим занимается COM интерфейс IUnknown. Он позволяет также узнать функции неизвестных COM интерфейсов для работы с ними.

При работе с DCOM ту же функцию выполняет ISystemActivator, позволяя обратиться к неизвестным DCOM интерфейсам, являющимися по сути теми же COM объектам, и работать с ними. ISystemActivator вызывается каждый раз при новом DCOM подключении.

Рисунок 4. Пример, как выглядит DCOM в Wireshark

Также IUnknown интерфейс дает возможность вызывать и другие функции COM объекта напрямую, фактически сводя всю работу с COM объектами до одной лишь функции IUnknown интерфейса. Тоже самое выполняет и интерфейс IDispatch для DCOM, позволяя выполнять любую функцию в мире DCOM через него. Поэтому, если мы взглянем на трафик, то увидим сначала вызов ISystemActivator, а потом только лишь обращения к IDispatch, вне зависимости от того какую DCOM функцию использует клиент.

Рассказывая про ALPC, мы упомянули, что эта технология используется только локально. Но это, конечно, не совсем правда, так как ALPC задействован чуть ли не во всех компонентах Windows. Поэтому, так или иначе, любое действие, в том числе и удалённое, будет прямо или косвенно применять ALPC. Это особенно интересно в контексте DCOM, потому что он напрямую использует ALPC на локальной машине, при этом будучи вызванным удалённым пользователем.

Схема вариантов RPC-подключений

Подведем итог вышесказаного в виде схемы вариантов подключения к удалённой машине, отражающей возможные пути со стороны клиента, которые в том числе доступны и для атакующего. Как видим из рисунка 5, все не так просто.

Рисунок 5. Возможные способы подключения к RPC серверу

Способы мониторинга

Разобравшись с вариантами RPC‑подключений, и, как следствие, с потенциально возможными действиями со стороны атакующего, рассмотрим, варианты мониторинга, которые нам может предоставить сама операционная система: ETW, журналы безопасности, SACL, RPC Filtering, RPC Firewall и сетевой трафик.

И начнем с технологии, на базе которой строится функционал для логирования событий в операционной системе Windows — Event Tracing for Windows (ETW).

Event Tracing for Windows

Event Tracing for Windows или сокращено ETW имеет множество, так называемых, провайдеров, которых в ОС более нескольких тысяч. Они позволяют отслеживать через события как отдельные технологии, так и конкретные процессы. Часть провайдеров формируют вполне понятные для обыденного пользователя события, другая же, бОльшая часть, используется исключительно только самой Microsoft для отладки.

ETW предоставляет возможность смотреть события вызовов RPC функций через стандартную оснастку Event Viewer. ETW провайдеры, связанные с RPC, представлены в таблице ниже.