Служба очереди сообщений windows

Службы очереди сообщений

Службы очереди сообщений (Microsoft Message Queuing Services, MSMQ) — сервис, входящий в стандартную поставку Microsoft Windows 2000 Server. С помощью MSMQ приложения, работающие в разное время, могут связываться через разнородные сети и системы, способные временно работать автономно. Приложения посылают сообщения MSMQ и используют очереди MSMQ — это позволяет быть уверенным, что сообщение рано или поздно достигнет адресата. MSMQ обеспечивает гарантированную доставку сообщений, интеллектуальную маршрутизацию, защиту и передачу сообщений, основанную на приоритетах.

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

Программные продукты с такими возможностями часто называют программным обеспечением поддержки очередей сообщений, программным обеспечением с промежуточным накоплением или средствами среднего уровня, ориентированными на сообщения (MOM, Message-Oriented Middleware).

Особенности и возможности службы MSMQ: .

Установка MSMQ. Чтобы добавить или удалить службу:

Картинка с сайта: lib.qrz.ru

Рис 22.18. Установка служб очереди сообщений

Служба MSMQ в Windows NT 4.0 и Windows 2000. Перечислим общие задачи управления службой MSMQ. Интерфейс пользователя для выполнения этих задач отличается в Windows 2000 от интерфейса в Windows NT 4.0.

В табл. 22.6 перечислены отличия в терминологии и в архитектуре предыдущих версий от текущей версии MSMQ.

Таблица 22.6. Управление службой MSMQ в Windows 2000 и в Windows NT 4.0

Управление службой MSMQ. Управление MSMQ на локальном компьютере осуществляется при помощи оснастки Управление компьютером — узел Службы и приложения | Очередь сообщений. Основное управление объектами MSMQ в организации осуществляется с применением оснастки Active Directory — пользователи и компьютеры. Для управления MSMQ в организации:

Уровень сложностиСредний

Время на прочтение9 мин

Количество просмотров4K

Введение

В конце апреля 2023 был опубликован PoC для уязвимости CVE-2023-21769 в сервисе очереди сообщений MSMQ. Это одна из трёх уязвимостей, обнаруженных в MSMQ и запатченных в апрельском обновлении ОС Windows (1, 2, 3). Опубликованный PoC реализует уязвимость отказа в обслуживании сервиса MSMQ. Две другие уязвимости – удалённый BSoD и RCE, названная Queue Jumper. По информации от MSRC с помощью этих уязвимостей можно было взять под контроль практически все версии ОС Windows, на которых доступен и активен MSMQ. Серьёзно, не правда ли?

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

Поэтому в данной заметке мы на простом примере проведём идентификацию патча и сравнительный анализ бинарного кода, немного познакомимся с проприетарным протоколом MQQB, и проанализируем уязвимость, поехали!

Идентификация патча

MSMQ является одной из технологий Windows для распределённого взаимодействия приложений, по умолчанию доступной на всех современных ОС данного семейства. Более подробно о нём можно узнать на Вики и в документации MSDN, здесь лишь отметим, что MSMQ реализует один из способов удалённого взаимодействия между приложениями с использованием сервера очередей, который получает и хранит отдельные сообщения или целые транзакции, и пересылает их приложению-адресату, когда появляется такая возможность.

Активируем этот сервис в опциях нашей Windows 10 (желательно на виртуальной машине), то в TCPView можно убедиться, что указанный в PoC TCP-порт 1801 прослушивается сервисом mqsvc.exe:

Картинка с сайта: habr.com

Подключимся к нему отладчиком WinDBG и запустим обнаруженный ранее PoC. Возникает исключение Access Violation из-за попытки записи по недоступному адресу:

Картинка с сайта: habr.com

По трассировке стека видно, что ошибка возникает в потоке, исполняющем библиотеку MQQM.dll, в конструкторе класса QmPacket, при записи 0x0C в запрещенную область памяти. Возможно, что уязвимость содержится именно в этой процедуре.

Скачаем патч с сайта MSRC или каким-либо другим способом, и найдем в нем библиотеку MQQM.dll, запустим анализ в дизассемблере IDA Pro. Стоит отметить, что Microsoft поставляет отладочные символы для данной библиотеки, поэтому нужно дать IDA Pro возможность скачать их, это очень облегчит анализ.

Сравнительный анализ патча

Воспользуемся Bindiff или Diaphora поиска патча в библиотеке. Diaphora это активно развивающийся проект, и в данном случае был использован именно он, однако архитектурно Diaphora не очень подходит для больших файлов, так как экспортирует данные IDA Pro в БД mysql, а затем сравнивает их с другой экспортированной таким же образом БД, и всё это на 100% Python. BinDiff сравнивает напрямую IDB-файлы и является нативным приложением, поэтому работает значительно быстрее, но для исследуемой библиотеки размером 1.2 МБ это не так критично.

Как правило, при анализе патча нас интересуют процедуры, которые слегка подкорректированы (из эмпирического предположения, что фикс не меняет всю логику работы программы). Сравним две версии программы:

Картинка с сайта: habr.com

Во вкладке Partial matches Diaphora показывает, что подмеченный нами ранее конструктор CQmPacket , в котором происходит краш при использовании PoC, как раз удовлетворяет данному критерию, коэффициент похожести между двумя его версиями — 0.720. Помимо этого небольшим изменениям подверглись ряд методов *::SectionIsValid. Что же изменилось в конструкторе CQmPacket? Отметим, что функция довольно объёмная, изменения в ней размазаны по всему телу:

Картинка с сайта: habr.com

Если приглядеться к добавленным/изменённым блокам, можно заметить использование новой процедуры GetNextSectionPtrSafe и методов вида *::GetNextSectionSafe вместо методов *::GetNextSection:

Картинка с сайта: habr.com

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

В PoC указано, что в обновленной версии при попытке эксплуатации уязвимости выводится строка Next section is behind packet end. Именно эта строка выводится в проверках GetNextSectionPtrSafe, то есть ошибка триггерится в ней, вот её декомпилированный и аннотированный код:

Картинка с сайта: habr.com

Данная процедура используется для того, чтобы безопасно сместить указатель на величины, указанные во втором и третьем аргументах. При этом осуществляется проверка, что смещения и полученный указатель не переполнились (в процедуре SafeAddPointersEx) и не вышли за пределы конца пакета (именно этот путь триггерится в PoC). Осталось только понять, что это за секции, и как контролировать их в пакете. А значит пришло время немного изучить данный бинарный протокол.

Анализ обработчика протокола

Уязвимый сетевой сервис работает по протоколу MQQB. Документация на него является общедоступной, поэтому разобрать отдельный пакет не так уж сложно.

Пакет MQQB отправляемый клиентом может состоять из множества секций, описанных в документации. Обработка таких сложных и вариативных структур всегда подвержена ошибкам, и недостаточные проверки формата данных в программах, написанных на C/C++ ­- лакомый кусочек для исследователей. По умолчанию пакет начинается с 16-байтовой структуры BaseHeader. Вот её поля на примере пакета из PoC:

Картинка с сайта: habr.com

Поле версии должно равняться 0x10, а сигнатура – 0x4C494F52 (LIOR), иначе пакет будет отброшен сервисом. В поле size размещается полный размер пакета. После структуры BaseHeader в пакете располагается структура UserHeader. Вот её неполный формат в контексте нашего пакета:

Картинка с сайта: habr.com

С подробным описанием структуры можно ознакомиться по ссылке. Первые 32 байта – это 2 поля UUID отправителя и получателя. Далее идут поля времени получения и отправления (0xFFFFFF и 0x4C494F52) и ID сообщения (0x3805). И наконец, наиболее важное для нас поле располагается по смещению 0x28 (0x38 от начала пакета), это битовая структура флагов пользовательского заголовка (UserHeaderFlags), которая равняется 0x201726D0 в PoC. По этим флагам сервис определяет, какие секции содержатся в пакете. Полный формат флагов представлен в той же ссылке, а на следующем рисунке представлены эти флаги для пакета с PoC:

Картинка с сайта: habr.com

Как видно из рисунка, многие среди прочих в заголовке установлены биты msg_prop_hdr и soap_hdr, значит данные секции содержатся в пакете. Попробуем понять, как они обрабатываются в программе. Что же происходит, когда программа понимает, что внутри есть эти секции? Поищем доступ к этому флагу в процедуре (1<<28 == 0x10000000), и найдём следующий блок кода:

Картинка с сайта: habr.com

Обнаруживается интересная схема: проверяется текущий указатель смещения в пакете nextSection (строки 234, 236), сохраняется как указатель на секцию, затем из пакета извлекается смещение для следующей секции (строка 239) и опять проверяется на нахождение этой секции в пределах пакета, и новая секция снова сохраняется в структуре СQmPacket. И наконец, перед выходом из блока, пересчитывается nextSection, снова используя смещение из данных пакета (245), и после этого nextSection не проверяется. Также заметим, что выражение 2*size + 0xB скорее всего означает, что в секции должны содержаться size двухбайтовых объектов (вероятно, символов Unicode-строки), и заголовок секции длиной 0xB.

Проверим наши догадки, найдём информацию об этой секции в документации. Действительно, размеры представлены в виде размеров Unicode строк, только это не две Soap-секции, а заголовок Soap-секции и её тело. Вот что пишет Microsoft по поводу поля смещения в header и body:

A 32-bit unsigned integer that specifies the length of the Header/Body field. This field MUST be set to the number of elements in the Unicode Header/Body field, including the terminating null character. This field has a valid range between 0x00000000 and the size limit imposed by the value of BaseHeader.PacketSize.

И как мы уже увидели в коде, если для Header результирующий указатель проверяется, то для Body это этого не происходит. Возможно, оно проверяется где-то далее по коду, ведь мы уже видели в начале блока проверку nextSection.

А вот и нет! Если секция Soap была последней при обработке, то управление перейдет к последнему блоку кода, который инициализирует конец пакета какими-то данными:

Картинка с сайта: habr.com

Именно на этой строчке кода происходит падение в PoC. Тут-то и сходятся звёзды — недоверенные данные гибкого формата на месте дополняются во время обработки, и всё это реализовано на небезопасной арифметике указателей в сервисе, имеющем доступ к драйверу ядра.

Таким образом мы пришли к следующему упрощенному представлению CQmPacket::CQmPacket:

Картинка с сайта: habr.com

Процедура состоит из последовательности условных переходов на блоки обработки каждой секции пакета. И действительно, если после Soap-секции будет обработка какой-либо другой секции, то указатель nextSection будет проверен и программа сообщит об ошибке в обработке пакета. А если нет, то управление перейдёт к последнему блоку (отмечен красным на диаграмме), и программа начнёт работать с непроверенным указателем. Именно таким образом при обработке пакета из PoC nextSection увеличивается далеко за пределы границ пакета и происходит запись по недоступным адресам. Поэтому корректный обработчик пакета должен проверять указатель nextSection после обработки каждой секции, и в процессе этой обработки.

Также отметим, что в случае современных ОС семейства Windows мы имеем дело с 64-битным адресным пространством, а смещения в пакетах – 32-битные, т.е. потенциально возможно сместить указатель записи только на 2*2^(32) + 11 байт вперёд. Это является уязвимостью, однако возможность её использования для чего-либо опасного зависит от многих факторов.

В данном случае, буфер в котором находятся наши данные всегда предшествует высоким Usermode-адресам процесса:

Картинка с сайта: habr.com

На рисунке выделена область памяти 0x0000025AB95E0000, в которой находится наш пакет (и другие пакеты, полученные процессом). Эта область является отображением в память временного файла C:\Windows\System32\msmq\storage\p000000d.mq для хранения пакетов очереди. Однако следующие доступные адреса находятся в 0x00007DF4********, и до них никак не добраться из нашего буфера имея лишь 4-байтовое смещение.

Для дальнейшей проработки данного вектора необходимо проверить возможность перехода данных пакета в другие области памяти, то есть осуществить Taint-анализ. За аллокацию объектов пакетов очереди сообщений отвечает драйвер MQAC.SYS, и, вероятно, уязвимость, вызывающая BSoD связана именно с ним.

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

Сопутствующие работы

На момент написания статьи никаких общедоступных исследований об уязвимостях Queue Jumper не было. Но впоследствии появился ряд работ в данном направлении. Приведу их список в хронологическом порядке, чтобы вы могли узнать ещё больше об MSMQ.

17 мая 2023: статья на китайском от исследователя zoemurmure, в которой также приведён анализ данного PoC. Однако в ней делается предположение о возможности перезаписи не только по положительным смещениям от пакета, но и по отрицательным, что не является верным.

1 июня 2023: статья на английском от исследователя Rick Osgood. Он копнул глубже, и сумел осуществить считывание памяти с помощью этих уязвимостей.

Заключение

В результате анализа данной уязвимости мы ознакомились с базовыми приёмами Patch diffing’а (сравнительного анализа патчей) на уровне двоичного кода. По предыдущим публикациям заметно, что для некоторых читателей тематика обратной разработки представляет повышенный интерес, поэтому приведу небольшой список литературы, полезной в рамках настоящей статьи.

• IDA Pro Book либо же The Ghidra Book – в зависимости от предпочитаемого вами основного инструмента анализа (PDF-ки легко гуглятся).

• Денис Юричев – “Reverse Engineering для начинающих”. Ещё одна классическая книга, очень полезная для начинающих и доступная на русском языке.

• Patch Diffing in the Dark – туториал по патч диффингу от Vulnerability Research Centre.

Как следует из нашей и остальных работ по теме MSMQ, защититься от сетевых атак с использованием уязвимостей из набора Queue Jumper можно запретив трафик по 1801 порту, либо проверяя каждый пакет MSMQ на корректность, то есть проверяя, что указатель nextSection не выйдет за границы пакета при его обработке.

Учитывая гибкую структуру пакета, просто идентифицировать протокол и проверить значение по какому-либо смещению не выйдет – для обнаружения атаки нужен полноценный парсер MQQB-пакетов. Так как документация на формат пакетов протокола и декомпилированный код разбора пакета доступны, разработка такого парсера возможна без особых усилий по реверс-инжинирингу.

Ввиду того, что уязвимый сервис доступен для активации практически во всех актуальных версиях Windows, пользователям, как и всегда, рекомендуется не пропускать обновления безопасности ОС.

Локально проверить наличие сервиса можно с помощью команды sc query "msmq", а также через GUI «Служб», и проверкой прослушиваемого сервисом порта (1801) через TCPView или powershell: Get-Process -Id (Get-NetTCPConnection -LocalPort 1801).OwningProcess. При обнаружении активного сервиса возможна проверка уязвимости с помощью PoC, упомянутого в начале статьи. Если в результате использования PoC происходит падение сервиса, рекомендуется отключить сервис / ограничить к нему доступ и приступать к обновлению ОС.

Понравился материал? Пишите свои замечания и вопросы в комментариях!

Наши ресурсы

• https://www.usergate.com/ru/security-reports

• https://t.me/usergatenews/

• mrc@usergate.com

Microsoft Message Queue (MSMQ) Server is a messaging protocol developed by Microsoft that allows applications running on separate servers/processes to communicate with each other. MSMQ is part of Microsoft’s messaging infrastructure, providing a way for applications to send and receive messages over the network asynchronously.

MSMQ is often considered a legacy technology, as it has been around since the late 1990s. It was more commonly used in enterprise applications for system integration and in scenarios where offline capabilities were needed.

In this article:

1. What is MSMQ?
2. Key Features and Benefits of MSMQ
3. MSMQ in Action: Usage Scenarios
   • Usage Scenario
   • Practical Coding Example
4. Comparing MSMQ with Modern Alternatives
5. The Legacy of MSMQ and Current Trends
6. Conclusion
7. References

1. What is MSMQ?

Microsoft Message Queue (MSMQ) is a technology developed by Microsoft for providing asynchronous communication between distributed applications in an enterprise environment. MSMQ allows applications to send and receive messages via queues, which are stored on the file system and managed by the MSMQ service. This message queuing system enables decoupled communication, where applications do not need to interact with each other directly or be online simultaneously to exchange messages.

Картинка с сайта: networkencyclopedia.com

Asynchronous Messaging in MSMQ:

• Queue-Based Communication: Applications send messages to queues, and recipient applications retrieve these messages from the queues. This setup allows for asynchronous processing, where the sender and receiver do not need to operate or be available at the same time.
• Handling Network Fluctuations: MSMQ is designed to handle intermittent network connections gracefully. Messages are queued locally and transmitted once the network is available, ensuring message delivery is not dependent on real-time network conditions.

2. Key Features and Benefits of MSMQ

Key Features

MSMQ comes with a host of features that make it a robust solution for enterprise-level message queuing:

Reliable Delivery:

• MSMQ guarantees the delivery of messages, ensuring that each message is delivered once and only once. This reliability is crucial for applications where data integrity is paramount.

Transactional Messages:

• MSMQ supports transactional processing of messages. This means that either all messages in a transaction are successfully delivered and processed, or none are, maintaining data consistency across distributed systems.

Security:

• Security in MSMQ is multifaceted, including encryption for message privacy, authentication to ensure messages come from legitimate sources, and authorization controls to manage who can send and receive messages.

Offline Operations:

• MSMQ can store messages in queues even when the network is down or the recipient application is offline. This capability ensures that message processing and delivery can continue once the application or network becomes available.

Benefits in Enterprise Environments

• Decoupling of Applications: MSMQ allows applications to operate independently, enhancing system scalability and robustness.
• Improved Performance: By enabling asynchronous communication, MSMQ allows applications to offload heavy processing, thereby not blocking other operations.
• Flexibility and Scalability: MSMQ supports a wide range of scenarios from simple point-to-point messaging to complex routing and prioritization of messages, making it versatile for various enterprise needs.
• Enhanced Reliability: The assurance of message delivery and transactional integrity makes MSMQ suitable for critical business processes where data accuracy is essential.

In enterprise environments, MSMQ’s ability to provide reliable, secure, and scalable messaging solutions makes it an important tool in the arsenal of system integrators and application developers, particularly in scenarios requiring robust communication mechanisms.

3. MSMQ in Action: Usage Scenarios

MSMQ Usage Scenarios

Microsoft Message Queue (MSMQ) finds its utility in a variety of scenarios, particularly in environments where reliable, asynchronous communication is essential. Its use cases span across different domains, showcasing its flexibility and robustness.

System Integration:

• In large enterprises, different systems often need to communicate with each other. MSMQ facilitates this by allowing systems to exchange information through messages, regardless of the languages or platforms they are built on. This capability is invaluable in scenarios where legacy systems need to be integrated with newer applications.

Business Process Automation:

• MSMQ is instrumental in automating business processes. For instance, in a supply chain management system, MSMQ can be used to queue orders, inventory updates, and shipping notifications, ensuring that each component of the supply chain communicates effectively, even under heavy loads or network disruptions.

Financial Transactions:

• The financial sector leverages MSMQ for transaction processing. The transactional messaging feature ensures that operations such as transfers or payments are completed reliably and in the correct order, a critical requirement in financial systems.

Healthcare Applications:

• MSMQ is used in healthcare applications for transmitting patient data, lab results, and other critical information between systems. Its ability to function offline ensures that data transfer is not hindered by intermittent network issues, crucial in healthcare settings.

Retail Operations:

• In retail, MSMQ can manage communication between point-of-sale systems and inventory management systems, helping in keeping stock levels updated in real-time and processing sales transactions efficiently.

3.2 Practical Coding Example

Below is a simple example of how a basic MSMQ application might be coded in C#. This example includes creating a queue, sending a message to the queue, and receiving a message from the queue. Note that this is a basic demonstration intended for educational purposes and may need to be adapted for specific use cases.

First, ensure that the MSMQ feature is installed on your Windows machine and add a reference to System.Messaging in your project.

Creating a Queue:

using System.Messaging;

...

// Check if a specific queue exists. If not, create it.
string queuePath = @".\Private$\MyTestQueue";
if (!MessageQueue.Exists(queuePath))
{
    MessageQueue.Create(queuePath);
}

Sending a Message to the Queue:

...

// Create a new message queue instance
MessageQueue myQueue = new MessageQueue(queuePath);

// Create a new message
Message myMessage = new Message();
myMessage.Body = "Hello MSMQ!";

// Send the message to the queue
myQueue.Send(myMessage);

Receiving a Message from the Queue:

...

// Set the formatter to indicate body type
myQueue.Formatter = new XmlMessageFormatter(new Type[] { typeof(string) });

// Receive and format the message
try
{
    Message myReceivedMessage = myQueue.Receive();
    string messageContent = myReceivedMessage.Body.ToString();
    Console.WriteLine($"Received message: {messageContent}");
}
catch (MessageQueueException e)
{
    Console.WriteLine(e.Message);
}

This code demonstrates a basic use case of MSMQ where a message is created, sent to a queue, and then received from the queue. Remember, for a real-world application, you’ll need to handle exceptions more robustly and consider security and transactional messaging based on your requirements.

4. Comparing MSMQ with Modern Alternatives

While MSMQ has been a stalwart in the message queuing arena, the landscape of messaging technologies has evolved with newer players like RabbitMQ, Apache Kafka, and various cloud-native services.

RabbitMQ:

• A widely-used open-source message broker, RabbitMQ supports multiple messaging protocols. It is known for its flexibility, ease of deployment, and support for complex routing. Unlike MSMQ, RabbitMQ offers a broader range of features for message management and monitoring.

Apache Kafka:

• Designed for high throughput and scalability, Apache Kafka is more than just a messaging system; it’s a distributed streaming platform. Kafka excels in scenarios involving large amounts of data, providing capabilities for real-time analytics. It’s a different paradigm compared to MSMQ, focusing more on data streaming rather than traditional queuing.

Cloud-Native Services:

• Services like AWS SQS, Azure Queue Storage, and Google Cloud Pub/Sub provide scalable, managed queueing services with deep integration into their respective cloud ecosystems. These services offer high availability, automatic scaling, and ease of maintenance, which are challenging to achieve with self-managed solutions like MSMQ.

Comparison:

• MSMQ’s strengths lie in its simplicity, integration with Windows-based systems, and support for offline operations. However, when it comes to scalability, cross-platform support, and advanced monitoring and management features, modern alternatives often have the upper hand. For instance, RabbitMQ and Kafka provide better support for complex routing and distributed systems, while cloud-native services offer the advantages of cloud scalability and reduced maintenance overhead.

5. The Legacy of MSMQ and Current Trends

MSMQ, a venerable component of Microsoft’s technology portfolio, retains its relevance in certain legacy systems. In today’s landscape, the focus has shifted towards distributed, scalable, and cloud-native messaging solutions, positioning MSMQ more as a specialized tool within a broader, more diverse messaging toolkit.

6. Conclusion

Historically, MSMQ played a pivotal role in enabling asynchronous communication in IT environments, particularly within the Microsoft ecosystem. Its legacy continues in specific use cases where its particular features align with business needs, even as the industry gravitates towards more modern, scalable messaging platforms.

7. References

1. “Pro MSMQ – Microsoft Message Queue Programming” by Arohi Redkar, Ken Rabold, Richard Costall, Scot Boyd, Carlos Walzer.
2. “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” by Gregor Hohpe and Bobby Woolf
3. “Installing Message Queuing (MSMQ)“, Microsoft Learn
4. “Distributed Systems: Concepts and Design” by George Coulouris, Jean Dollimore, Tim Kindberg, and Gordon Blair