Dsb notification что это
Как продлить автономность Android, отключив только одну функцию
Наверное, каждый из нас, независимо от смартфона и ёмкости аккумулятора, пытается сберечь его ресурс и растянуть зарядку как можно дольше. Даже если у вас Galaxy S20 Ultra с батарейкой на 5000 мА*ч и высочайшей энергоэффективностью, скорее всего, для вас является вопросом чести вытянуть из него хотя бы лишние 20-30 минут. Добиться этого можно разными способами – от перевода смартфона в режим энергосбережения до отключения беспроводных интерфейсов и понижения частоты обновления экрана. Но почти всегда это компромисс, с которым приходится мириться. Однако есть такой способ, который и зарядку сэкономит, и вас не ограничит.
Увеличить автономность смартфона можно отключением одной незначительной функции
Я говорю о функции адаптивных уведомлений, которая впервые появилась в четвёртой бета-версии Android 10 около года назад. Эта функция позволяла смартфону самому анализировать важность входящих уведомлений и задавать им приоритет для последующей выдачи пользователю.
Как отключить адаптивные уведомления
Уведомления с низким приоритетом просто появлялись в самом низу шторки, не издавая никаких звуков, а уведомления с более высоким приоритетом приходили со звуком и располагались в самом верху выдачи, чтобы к ним было удобнее получить доступ.
В общем, штука удобная, но довольно ресурсоёмкая. Опыты показали, что распределение уведомлений по приоритетности требует дополнительной энергии. А её отключение позволяет эту энергию сберечь:
Отключите адаптивные уведомления, и автономность возрастёт
По умолчанию в Android функция адаптивных уведомлений появилась с выходом Android 11. Но это касается только тех смартфонов, у которых этой фишки раньше не было. Дело в том, что многие производители не стали дожидаться Google и внедрили адаптивные уведомления в свои прошивки сами.
После этого принцип поступления уведомлений немного изменится. Во-первых, начнёт казаться, что их стало поступать больше. Несмотря на то что фактически количество уведомлений не изменится, теперь вы будете получать звуковой сигнал о каждом из них, тогда как раньше часть из них приходила в тихом режиме.
Увеличение автономности Android
Прирост автономности будет зависеть от вашего сценария использования
Просто раньше, когда адаптивные уведомления были включены, смартфон считал их недостаточно важными для вас и игнорировал, дабы не отвлекать от более важных дел. Во-вторых, с отключением адаптивных уведомлений будет отключена их группировка в шторке. То есть отныне все уведомления будут отображаться там в хронологическом порядке.
Насколько сильно изменится автономность вашего смартфона после отключения функции адаптивных уведомлений, однозначно сказать сложно. Это зависит от множества индивидуальных показателей, характерных для одних пользователей и не характерных для других – от ёмкости аккумулятора до количества уведомлений, которые вы получаете в течение дня.
Ведь если в день вам приходит до десятка уведомлений, то скорее всего изменения во времени автономной работы будут отсутствовать вообще. Но, если вы подписаны на оповещения от множества разных сервисов и ежедневно получаете несколько сотен уведомлений, автономность может измениться более ощутимо.
Как бы там ни было, рассчитывать на кардинальный прирост во времени работы смартфона без подзарядки не стоит. Максимум, что можно ожидать, — это дополнительные 3-5% от предыдущих показателей автономности. Но, учитывая, что некоторые аппараты в режиме повышенного энергосбережения могут протянуть на таком остатке энергии даже целый день, отключение адаптивных уведомлений может иметь смысл.
Подозрительно: массовые смс с кодами активации от разных сервисов
С десятка номеров пришли однотипные смс, одно за другим — «Ваш код подтверждения…»:
Некоторые сообщения продублировались утром и вечером. Что это может быть?
Анна, кто-то мог отправить смс и вручную, вводя ваш номер на разных сайтах. Но более вероятно, что это работа автоматического скрипта — программного кода, который выполняет действия по заранее заданному алгоритму.
Попробую разобраться, чего хотел автор этого скрипта. Некоторые варианты выглядят безобидно, другие в будущем могут стоить вам денег. Вот что приходит на ум:
Обычная шутка
Начну с самого безобидного. Кто-то из знакомых, знающих ваш номер, решил ради шутки завалить ваш телефон сообщениями. Это делают с помощью программ, которые называются « смс-бомберы », или « смс-флудеры ». Не знаю, почему некоторые считают это смешным, но шутка достаточно популярная.
Как защититься. Если не планируете пользоваться сервисами, от которых пришли сообщения, просто заблокируйте имена отправителей.
Самозащита от мошенников
Создание баз номеров
Другая возможная цель такого скрипта — сбор информации. Скрипт пытается восстановить пароль на разных сервисах. Если процесс запустился, аккаунт с таким телефонным номером существует. Его вносят в базу номеров.
Использовать базу могут как угодно. Например, статистику о владельцах дисконтных карт одной торговой сети передадут в другую — и вы начнете получать от них уведомления об акциях и скидках. Или через некоторое время вам позвонит «сотрудник банка» и попытается выманить данные карты.
Как защититься. Существуют сервисы, которые подменяют телефонные номера, поэтому доля паранойи не помешает. Если вам звонят и просят срочно назвать три цифры с обратной стороны карты, чтобы заблокировать списание денег, не верьте — даже если это звонок с номера банка, указанного на карте. Положите трубку и перезвоните в банк.
Еще вариант защиты — завести отдельную симкарту для регистрации на сайтах и больше нигде ее не использовать. Если на этот номер позвонят или напишут из банка, вы будете точно знать, что это мошенник.
Попытка регистрации с подбором кода
Для рассылки спама с разводом и «мусорной» рекламой мошенники обычно создают аккаунты на чужое имя или используют взломанные. Смс с кодами активации могут говорить о том, что ваши аккаунты пытаются взломать — или зарегистрировать новые на ваш номер телефона.
При регистрации сервисы отправляют на указанный номер мобильного код проверки. Вводя этот код, вы подтверждаете, что номер принадлежит вам и вы соглашаетесь с регистрацией. У мошенника нет вашего телефона, но он может попытаться подобрать присланный вам код.
Чем длиннее код, тем сложнее это сделать. Например, если код состоит из четырех цифр, существует 10 тысяч разных вариантов, а если из шести — вариантов уже миллион.
Скрипт можно научить проверять все эти варианты и автоматически вводить коды проверки один за другим — от 000000 до 999999. Здесь все зависит от защиты сайта: ограничивает ли он количество попыток, если ограничивает, то сколько их. И можно ли повторить процедуру с тем же номером через какое-то время.
Чем больше попыток дает сайт, тем выше вероятность, что скрипт успеет подобрать код и подтвердить «вашу» учетную запись без доступа к телефону и тексту смс. Например, в 2017 году на «Хабре» писали про угон аккаунтов одного каршеринга.
Многие сайты защищены хуже, чем кажется. Специально для этой статьи я написал небольшой скрипт и попытался с его помощью подобрать шестизначный код подтверждения одной социальной сети. На удивление, сайт разрешил моему скрипту ввести больше ста разных кодов подтверждения — и только после этого сказал, что я слишком часто пытаюсь это сделать, и попросил подождать 10 минут.
Я не стал перезапускать скрипт. Но даже за одну попытку вероятность подбора — 100 к 1 000 000, то есть 0,01%. Если перебрать 10 тысяч номеров, один из них удастся подтвердить. А если длина кода всего четыре символа, то при тех же условиях хватит ста номеров, чтобы подобрать код к одному из них и получить доступ к подтвержденному аккаунту. После этого можно рассылать с него спам от чужого имени.
Анна, вы написали, что сообщения приходили с определенными интервалами, утром и вечером. Это увеличивает вероятность того, что речь идет о подборе кода. Мошенник подождал предложенное сайтом время и снова запустил свой скрипт. Возможно, пытались взломать ваши аккаунты или зарегистрировать новые на ваш номер телефона.
Как защититься. К сожалению, гарантированной защиты от такого взлома нет. Не исключено, что мошеннику удастся подобрать код и активировать аккаунт. Отдельная симкарта для интернета не поможет: мошенник все равно сможет зарегистрировать аккаунт на основную. Тут все зависит от безопасности конкретного сайта.
Если какие-то сайты вам важны или у вас уже есть там аккаунт, попробуйте сменить пароль или написать в техподдержку и описать ситуацию. Возможно, ваш аккаунт заблокируют и создадут новый или предложат какой-то другой вариант.
Утечка паролей
Время от времени в руки злоумышленников попадают базы данных с паролями пользователей различных сервисов — из-за взломов, утечек и социальной инженерии. Пароль также могут украсть с помощью троянских программ или вирусов. Более того, вы сами могли нечаянно передать пароль мошенникам, например на поддельном сайте.
Если у вас одинаковый пароль на многих сайтах, это дополнительный риск. Узнав ваш пароль к одному сайту, мошенники получают доступ и к остальным. Проверяют это тоже с помощью скрипта, который вводит украденный у вас пароль на всех сайтах подряд. Где-то пароль не подойдет, где-то аутентификация двухфакторная — сначала надо ввести пароль, потом код из смс. Если пароль подошел на нескольких таких сайтах, то и сообщений будет много.
Дальше код подтверждения попытаются подобрать по уже описанной схеме.
Как защититься. Используйте для каждого сайта уникальный пароль. Это не так сложно, как кажется: например, добавьте к вашему обычному паролю несколько первых или последних символов из названия сайта. Так вы хотя бы защититесь от автоматического перебора, если мошенники украдут один из паролей.
Маскировка важного смс
Последний вариант, который мне показался возможным, — попытка скрыть какое-то важное сообщение. Возможно, злоумышленник украл данные вашей карты и не хотел, чтобы вы увидели смс о снятии средств. Поток сообщений отодвинет нужное на второй экран, и есть шанс, что вы его пропустите и не заблокируете карту вовремя. Надеюсь, это не ваш случай.
Как защититься. Внимательно проверяйте все пришедшие сообщения и блокируйте смс от ненужных сервисов. Так проще убедиться, что сообщение от банка о снятии крупной суммы или от мобильного оператора о замене симкарты не затерялось в спаме.
Если увидели что-то подозрительное, пишите. Возможно, кто-то пытается украсть ваши деньги.
Windows Notification Facility: cамая недокументированная поверхность атаки
Под катом представлен перевод презентации «The Windows Notification Facility: The Most Undocumented Kernel Attack Surface Yet», представленной Alex Ionescu и Gabrielle Viala на конференции BlackHat 2018.
Что такое Windows Notification Facility (WNF)
Windows Notification Facility это механизм уведомлений (доступный как в ядре, так и в пользовательском режиме), который строится на модели издатель-подписчик (pubsub, Publisher/Subscriber). Механизм был добавлен в Windows 8: частично для того, чтобы решить некоторые давние конструктивные ограничения в ОС, но также он должен был послужить основой для реализации Push-уведомлений, аналогичных iOS/Android.
Его ключевой особенностью является то, что это слепая (в основном — без регистрации) модель, которая допускает неупорядоченную подписку и публикацию. Под этим подразумевается, что потребитель может подписаться на уведомление даже до того, как уведомление было опубликовано его источником. И что тот, кто генерирует события, не обязан «регистрировать» уведомление заранее.
Помимо всего прочего механизм поддерживает:
Почему появился WNF
Рассмотрим канонический пример: есть драйвер, который хочет знать о том, что был подключен том с доступом на чтение и запись. Чтобы уведомить об этом, Autochk (аналог fsck в Windows) сообщает о событии под названием VolumesSafeForWriteAccess. Но чтобы сообщить о событии нужно сначала создать сам объект события.
Нам так же надо знать, что Autochk уже работает над томом, но еще не сигнализировал событие, которого мы ждем. Плохое решение: сидеть в цикле со sleep(), проверяя наличие события, и когда событие будет создано — подождать его.
Но после выхода из приложения Windows все его дескрипторы закрываются. А когда у объекта нет дескрипторов, он уничтожается. Так кто же будет держать это событие?
Без WNF решение состоит в том, чтобы ядро ОС создало событие до того, как загрузятся какие-либо драйверы, и чтобы Autochk открывал его, как это делал бы потребитель, но вместо ожидания он должен сигнализировать это событие.
Имена состояний (State Names) WNF
В мире WNF имя состояния — это 64-х битное число. Но есть хитрость — на самом деле это закодированная структура. Имя состояния имеет версию, время жизни, область видимости, флаг постоянства данных и уникальный порядковый номер.
Но эти данные станут доступны, только если мы про-XOR’им 64-х битное число с магической константой:
Время жизни (Lifetime) имени состояния
Имя состояния WNF может быть (WNF_STATE_NAME_LIFETIME):
Первые три связаны с соответствующими ключами в реестре, где будет храниться информация о состоянии:
У общеизвестных имен есть своя особенность: их нельзя зарегистрировать. Такое имя уже должно быть представлено в реестре на момент загрузки системы. Постоянные и устойчивые имена требуют для своего создания включенную привилегию SeCreatePermanentPrivilege (как и другие глобальные объекты). Устойчивые имена живут и вне процесса-регистратора, а постоянные имена переживают перезагрузку системы.
Область видимости (Scope) данных
Область видимости данных определяет первую границу безопасности вокруг имени состояния WNF, она определяет кто видит его и имеет у нему доступ. Область видимости имени состояния может быть:
Помимо обеспечения границ безопасности, области видимости WNF могут использоваться для предоставления разных экземпляров данных для одного и того же имени. Ядро (как и в случае с другими механизмах безопасности) обходит проверки доступа к состоянию. Привилегия TCB позволяет осуществлять междиапазонный (cross-scope) доступ к именам состояний WNF.
Область видимости «система» и область видимости «машина» это глобальные области видимости. Они не имеют собственных идентификаторов (они используют разные глобальные контейнеры). Область видимости пользовательской сессии использует в качестве ID идентификатор сессии (session ID). Область видимости конкретного пользователя использует в качестве идентификатора SID этого пользователя. В качестве идентификатора области видимости процесса выступает адрес объекта EPROCESS.
Порядковые номера (Sequence Numbers)
Чтобы гарантировать уникальность, каждое имя состояния имеет уникальный 51-битный порядковый номер. Общеизвестные (well-known) имена включают в свой порядковый номер 4-символьный тег семейства, а оставшиеся 21 бит используются в качестве уникального идентификатора. Постоянные имена хранят свой увеличивающийся номер значением реестра «SequenceNumber». Устойчивые и временные имена используют общий возрастающий счетчик, который расположен в глобальной переменной. Эти данные хранятся и обрабатываются отдельно для каждого контейнера (per-silo) и доступны в PspHostSiloGlobals->WnfSiloState.
Внутри Microsoft каждое имя WNF имеет «дружественный» идентификатор, который используется в коде, иногда он хранится в пространстве глобальных имен с тем же именем. Например — символ nt!WNF_BOOT_DIRTY_SHUTDOWN, который имеет значение 0x1589012fa3bc0875. После XOR’а с магической константой WNF_STATE_KEY получаем значение 0x544f4f4200000801, которое можно побитово трактовать как:
Системные вызовы для работы с WNF
Системные вызовы ядра позволяют регистрировать и удалять имена состояний WNF, публиковать и получать данные имен состояний WNF, а так же получать различные уведомления от WNF.
Регистрация имени состояния WNF
За исключением общеизвестных имен (как уже помянуто ранее), имя состояния WNF может быть зарегистрировано во время работы ОС:
Существует симметричный системный вызов ZwDeleteWnfStateName с помощью которого можно удалить зарегистрированное имя состояния (опять же, кроме общеизвестных).
Публикация данных состояния WNF
Чтобы задать или изменить данные имени состояния WNF, можно использовать системный вызов ZwUpdateWnfStateData:
Для удаления (очистки) данных имени состояния WNF существует симметричный системный вызов ZwDeleteWnfStateData.
Получение данных состояния WNF
Для того, что бы запросить данные имени состояния WNF может использоваться следующий системный вызов (большинство параметров аналогичны функции Update):
Настоящая сила заложена в том, что API-функции Update и Query по факту не требуют зарегистрированного имени состояния WNF. А если имя не является временным (и у вызывающего кода есть достаточные привилегии), экземпляр имени может быть зарегистрирован в реальном времени!
Уведомления WNF
До сих пор мы предполагали, что потребитель знает, когда вызывать функцию получения данных. Но также есть блокирующие чтение, которое работает с использованием системы уведомлений (что ближе к истинной модели издатель-подписчик).
Во-первых, процесс должен зарегистрировать событие вызовом функции ZwSetWnfProcessNotificationEvent. Затем нужно вызвать функцию ZwSubscribeWnfStateChange, указав маску событий, что бы получить идентификатор подписки на выходе. События могу быть двух типов:
Затем необходимо дождаться события, которое было зарегистрировано. И всякий раз, как событие становится сигнальным, нужно вызывать функцию ZwGetCompleteWnfStateSubscription, которая возвращает WNF_DELIVERY_DESCRIPTOR.
Но у этих низкоуровневых API-функций есть проблема (спасибо Gabi за ее иследование): у каждого процесса может существовать только одно зарегистрированное событие.
Высокоуровневое API пользовательского режима (ntdll)
Когда дело доходит до уведомлений, все усложняется, поэтому Rtl-слой из ntdll.dll предоставляет более простой интерфейс:
Фактически, нет необходимости вызывать системные сервисы напрямую: достаточно использовать единую управляемую ntdll.dll очередь событий.
За кулисами содержимое WNF_DELIVERY_DESCRIPTOR преобразуется в параметры обратного вызова:
Для каждой новой подписки заводится запись, которая помещается в список, на который указывает глобальная переменная RtlpWnfProcessSubscriptions. Список строится на одном из полей WNF_NAME_SUBSCRIPTION, которое имеет тип LIST_ENTRY. Каждая из WNF_NAME_SUBSCRIPTION, в свою очередь, имеет еще одно поле LIST_ENTRY для организации списка из WNF_USER_SUBSCRIPTION с обратным вызовом и контекстом.
Высокоуровневое API уровня ядра (Ex)
WNF также предоставляет практически идентичные функции для кода режима ядра (которые можно использовать из драйвера): как через экспортированные системные вызовы, так и через высокоуровневые API-функции в исполнительной среде выполнения (Ex-слой).
Функция ExSubscribeWnfStateChange принимает на вход имя состояния, маски типов и адрес функции обратного вызова + контекст, а возвращает дескриптор подписки. Функции обратного вызова получают целевое имя, маску события, метку изменения, но не буфер или его размер.
Функция ExQueryWnfStateData по переданному дескриптору подписки читает текущие данные состояния. Фактически, каждый обратный вызов заканчивает тем, что вызывается функция ExQueryWnfStateData, чтобы получить данные, связанные с уведомлением.
И для подписок режима ядра, и для подписок пользовательского режима WNF (для отслеживания подписки) создает экземпляр структуры WNF_SUBSCRIPTION. Но для пользовательского режима некоторые поля не будут заполнены, например Callback и Context, так как для пользовательского режима адреса обработчиков хранит и обрабатывает ntdll.dll.
Структуры данных WNF
От переводчика: смотри следующий раздел.
Утилиты анализа WNF
От переводчика: тут стоит снова напомнить, что презентация велась не только Alex’ом, но еще и Gabrielle Viala. В частности, её авторству принадлежит описанный далее модуль WnfCom. Кроме того Gabrielle достаточно подробно описала внутренние структуры WNF (смотри иллюстрацию в предыдущем разделе). Большая часть ее слайдов, к сожалению, отсутствует в pdf презентации (указанной в качестве оригинала) или обозначена исключительно заголовками. Но:
И еще от переводчика: Если кто-то захочет дополнить текущий перевод содержимым слайдов Gabrielle или расширить переводом стенографии из любой части видеозаписи выступления — welcome. Для удобства добавления/изменения больших кусков могу опубликовать исходник перевода на github (или другом сервере системы контроля версий).
WnfCom
WnfCom это python-модуль (исходный код на github), который показывает возможность взаимодействия посредством WNF. Ключевые возможности:
WnfDump
WnfDump это утилита командной строки, написанная на C. Исполняемый файл можно найти в https://github.com/ionescu007/wnfun, выбрав под-директорию нужной разрядности. Утилита может быть использована для поиска информации об именах состояний WNF:
Поверхность атаки на WNF
В этом разделе (точнее его подразделах) пойдет речь о возможных атаках и интересных чувствительных данных WNF.
Раскрытие привелегированных данных
Читая тысячи имен состояний WNF, существующих в системе, можно отметить несколько, данные которых выглядят весьма интересно. В их числе были некоторые, данные которых подозрительно похожи на указатели или другие привилегированные данные.
После воспроизведения на нескольких машинах, в некоторых случаях удавалось обнаружить кучу, стек и другую привилегированную информацию, разглашаемую через границы привилегий. Отчеты об ошибках/уязвимостях были переданы в MSRC в июле, но исправлены в ноябре (уже после презентации). Например: через событие WNF_AUDC* утекало 4 килобайта стека!
Основные проблемы все те же, что мы видели в предыдущих исследованиях от j00ro, taviso, и других. Определенные имена состояний WNF содержат закодированные структуры данных с различными проблемами заполнения и/или выравнивания. В некоторых случаях утекает неинициализированная память.
От переводчика: перевод вступительной части документа Detecting Kernel Memory Disclosure with x86 Emulation and Taint Tracking от Mateusz Jurczyk aka j00ro.
Обнаружение имен состояний и разрешений
Первый подход состоял в том, чтобы обнаружить все возможные имена состояний, которыми можно было бы манипулировать злонамеренно. Для общеизвестных (well-known), постоянных (permanent) и устойчивых (persistent) имен перечисление выполнимо путем перечисления разделов реестра. Затем найденные значения можно сопоставить с дружественными идентификаторами (есть несколько мест, где их можно найти :))
Затем мы также можем посмотреть в реестре дескриптор безопасности (это первое, что находится в буфере данных). Дескриптор безопасности не каноничен: у него нет владельца и группы, поэтому технически он недействителен. Но нет никакой проблемы подставить поддельных владельца и группу, что бы исправить дескриптор безопасности.
Обнаружение временных имен состояний и их разрешений
Но с временными (temporary) именами описанные выше трюки не пройдут: их нет в реестре. И только ядро хранит в памяти структуры данных для них (!wnf). Но временные имена в действительности не так сложно перебрать (brute force):
Да, но оставшийся порядковый номер это 51 бит! Действительно… но не стоит забывать, что порядковые номера монотонно растут. И для временных имен последовательность сбрасывается до 0 при каждой загрузке. Условно, можно взять окно в миллион порядковый номеров: в цикле проверять существование каждого имени (начиная от 0) вызовом ZwQueryWnfStateNameInformation с запрашиваемым классом информации WnfInfoStateNameExist (учитывая, что ошибка доступа тоже говорит о существовании имени). Если очередной миллион имен не существует, то можно остановить перебор.
Это не дает нам полного дескриптора безопасности, но запустив код с разными привилегиями мы можем получить какое-то представление об ограничениях для разных учетных записей системы (Low IL/User/Admin/SYSTEM).
Перечисление подписчиков
В структуре WNF_PROCESS_CONTEXT одно из полей это голова списка (LIST_ENTRY) всех подписок этого процесса. Каждая подписка это отдельный экземпляр WNF_SUBSCRIPTION.
Мы можем повторить этот подход и для процессов пользовательского режима, но адрес обработчика (Callback) будет NULL, так как это подписчики режима пользователя. Поэтому нам необходимо присоединиться к пользовательскому пространству процесса, получить таблицу RtlpWnfProcessSubscriptions, а затем дампить список экземпляров WNF_USER_SUBSCRIPTION, каждый из которых уже содержит адрес обработчика (Callback). К сожалению, этот символ является статическим, что означает, что его нет в открытых символах, но его можно найти дизассемблированием. И снова стоит обратить внимание (по аналогии с CEA.SYS режима ядра), что многие среди обработчиков пользовательского режима используют агрегатор событий (EventAggregation.dll), который хранит обратный вызов в своем контексте.
Интересные и чувствительные имена состояний WNF
В этом разделе будет несколько интересных примеров того, как некоторые имена состояний WNF раскрывают информацию о системе.
Определение состояния системы и поведения пользователя с помощью WNF
Некоторые идентификаторы WNF могут быть использованы для получения интересующей информации о состоянии машины:
Другие идентификаторы WNF могут быть использованы для получения информации о действиях пользователя:
Альтернативы стандартным API уведомлений
Даже в ситуациях, когда определенные пользовательские действия уже имеют документированные API для уведомлений, эти API могут, например, генерировать новые записи в журнале событий/аудита. Иногда существуют соответствующие идентификаторы WNF для тех же отслеживаемых действий. И, если повезет, данные в WNF могут даже быть даже более детальными.
Есть и примеры, когда WNF может служить альтернативой API пользовательского режима, не имеющего эквивалента со стороны ядра:
Воздействие на систему с использованием WNF
Существует набор идентификаторов WNF, запись данных в которые приводит к изменению системы. Например: WNF_FSRL_OPLOCK_BREAK — получает, среди прочих данных (количество/размер), список PID’ов и уничтожает указанные процессы!
Внимательно изучить поведение всех подобных идентификаторов WNF пока еще не хватило времени, но многие из них выглядят очень интересно. Например: WNF_SHEL_DDC_(WNS/SMS)_COMMAND – размер буфера 4 килобайта, что указывает на широкие возможности существования ошибок его разбора.
Внедрение в процесс с использованием WNF
Основные техники внедрения кода в другой процесс включают в себя:
Использование WNF предоставляет еще пару способов передачи данных в целевой процесс:
Для того, что бы заставить процесс выполнить внедренный код обычно используют следующие механизмы ОС:
Однако другой подход может заключаться в анализе WNF_USER_SUBSCRIPTION целевого процесса (которые являются элементами списка из WNF_NAME_SUBSCRIPTION, на который ссылается RtlpWnfProcessSubscriptions). Функцию обратного вызова можно изменить (учитывая CFG ), а основную полезную нагрузку передать через данные уведомления (параметры 5 и 6 у функции обратного вызова).
Еще один подход может заключаться в том, что бы менять контекст обратного вызова: в контексте может быть, например, таблица виртуальных функций, где можно подменить адрес метода-обработчика.
Направления для дальнейших исследований
Большая часть событий WNF начинается с SEB_, они относятся к брокеру системных событий (System Events Broker). SystemEventsBrokerServer.dll и SystemEventsBrokerClient.dll являются высокоуровневыми API пользовательского режима. Вероятно, что некоторые из этих событий SEB затем анализируются внутри клиентов SEB, что маскирует некоторых истинных потребителей.
Многие из зарегистрированных обратных вызовов режима ядра и пользовательского режима принадлежат CEA.SYS или EventAggregation.dll. Они являются частью «библиотеки агрегации событий» (Event Aggregation Library), которая позволяет управлять обратными вызовами, на основании накопления определенного набора условий: могут быть заданы пороговые значения, или может быть задано условие того, что несколько WNF событий должны произойти в одно и то же время или в заданной последовательности, или условие возникновения хотя бы одного события из группы. По сути это конечный автомат вокруг событий WNF, позволяющий регистрировать собственные обратные вызовы. А реальные потребители скрыты за библиотекой агрегации событий.
От переводчика: Далее я хотел бы немного рассказать про исследования других авторов и дать соответствующие ссылки.
До презентации
Нельзя не отметить, что исследования Windows Notification Facility начались задолго до выступления Alex’а и Gabrielle. Одним из первых (известных мне) публичных исследователей является redp.
Он добавил дампинг структур WNF (задолго до выступления) в свой широко известный в узких кругах инструмент wincheck. Более того, есть прямые ссылки из работ Gabrielle Viala на то, что ее исследования опираются на посты redp, с которыми можно ознакомиться тут: http://redplait.blogspot.com/search/label/wnf.
После презентации
Не так давно был представлен PoC (исходный код на github) внедрения в explorer (полезная нагрузка — запуск notepad). modexp представил реализацию одного из возможных векторов атаки из перезентации: подмена поля Callback в WNF_USER_SUBSCRIPTION. Опубликованный код сводится к следующему алгоритму: