POC详情: 920de3bcd4805a745d97f4ce3a66d041e9e9aa4c

来源
关联漏洞
标题: Microsoft Message Queuing 安全漏洞 (CVE-2023-21554)
描述:Microsoft Message Queuing是用于实现需要高性能的异步和同步场景的解决方案。 Microsoft Message Queuing存在安全漏洞。以下产品和版本受到影响:Windows 10 Version 1809 for 32-bit Systems,Windows 10 Version 1809 for x64-based Systems,Windows 10 Version 1809 for ARM64-based Systems,Windows Server 2019,Wind
描述
CVE-2023-21554 PoC
介绍
# MSMQ Vulnerability Proof of Concept

This repository contains a ready-to-run proof of concept that targets Microsoft Message Queuing listening on TCP port 1801. This work is based on and uses materials from the original project at  
https://github.com/leongxudong/MSMQ-Vulnerability

This repository uses the binary artifacts provided by that project. The binary files included and referenced by the PoC are:
1. `establish_connection.bin`  
2. `connection_parameters.bin`  
3. `user_message.bin`  

# Description

This PoC attempts to reproduce the condition described in CVE 2023 21554 by sending a sequence of MSMQ protocol frames to a target host on port 1801. The PoC scripts only perform network-level activity and do not perform any post-exploitation actions. This project is intended for analysis and defensive verification in an isolated lab environment only.

# Files included

1. `CVE-2023-21554.py` — original PoC script that sends the three binary blobs in sequence  
2. `CVE-2023-21554.py` — attacker-side helper script that logs responses, hexdumps, timestamps, and socket-level errors. Use this script to obtain more useful attacker-side evidence  
3. `establish_connection.bin` — binary stage one payload from the original repository  
4. `connection_parameters.bin` — binary stage two payload from the original repository  
5. `user_message.bin` — binary stage three payload from the original repository  
6. `README.md` — this file

# Prerequisites

1. Python 3 installed on your attacker host  
2. Network access to the target host port 1801 and explicit permission to test that host  
3. A snapshot of the target virtual machine so you can revert changes after testing  
4. Tools to capture evidence for verification (for example Wireshark or tcpdump) and Sysinternals procdump for Windows

# How to run the PoC in a lab environment

1. Place the three binary files in the same folder as the PoC script  
2. Edit the PoC script or `CVE-2023-21554.py` to set the target IP address  
3. Start a network capture on your attacker machine for the target IP and port. Example command in a separate shell (replace the IP with your target):
    
    sudo tcpdump -i eth0 host 10.0.2.15 and port 1801 -w msmq_test.pcap

4. Run the enhanced check script to get timestamped logs and hexdumps

    python3 CVE-2023-21554.py

5. Save the PoC output and the network capture file for analysis

# How to tell if the PoC worked

## 1. Attacker side indicators
1. The `CVE-2023-21554.py` reports `connection_reset` or `orderly_close` immediately after a payload stage (these are explicit statuses printed by the helper).  
2. The PoC receives a non-trivial reply from the target (small, unusual reply bytes). Save and hexdump that reply for comparison.  
3. The network capture shows a TCP reset (RST) or other abnormal termination immediately after the exploit packets.

## 2. Target side indicators
1. The Message Queuing service process `mqsvc.exe` crashes or restarts at the time of the test.  
2. Windows Event Viewer contains Application or System events referencing an access violation or a faulting application name `mqsvc.exe`.  
3. A procdump captured at the time of the test shows an exception in the `mqsvc` process.

# Practical Wireshark steps and filters copy-paste ready

Replace `<TARGET>` with your target IP for each filter.

Show all traffic between attacker and target on the MSMQ port:
`ip.addr == <TARGET> && tcp.port == 1801`

Show only server-originating TCP RSTs:
`ip.src == <TARGET> && tcp.port == 1801 && tcp.flags.reset == 1`

Show packets that contain application data (non-empty TCP payloads):
`ip.addr == <TARGET> && tcp.port == 1801 && tcp.len > 0`

Show zero-length segments or FINs:
`ip.addr == <TARGET> && tcp.port == 1801 && (tcp.len == 0 || tcp.flags.fin == 1)`

Show retransmissions and TCP anomalies:
`tcp.analysis.retransmission || tcp.analysis.fast_retransmission || tcp.analysis.duplicate_ack`

## Steps to extract the server reply bytes (raw hexdump)
1. Locate the server packet of interest in the packet list pane. Look for small `tcp.len` values or the packet immediately before an RST.  
2. Right-click the packet → **Follow** → **TCP Stream**.  
3. In the Follow TCP Stream dialog choose **Show data as: Raw** and then **Save As** to export the exact bytes.  
4. Alternatively, select the packet and copy bytes from the **Packet Bytes** pane. Save the raw bytes/hexdump as evidence (for example `server_reply.hex`).

## How to tell whether the reset came from the target vs a middlebox
1. Confirm the **Source IP** of the RST matches the target. If it does, it strongly indicates the target host or its kernel closed the socket.  
2. If the RST source is a different on-path device, it usually indicates a middlebox or firewall dropped the connection instead. TTL differences and interface IPs can assist diagnosis.

## Timing correlation (important)
1. Note the timestamp difference between the exploit packet and the server reaction. Crashes or abrupt RSTs typically occur within tens to hundreds of milliseconds after the offending packet. Record these times as part of your evidence.

## Comparative test
1. Capture the same sequence against a known-patched host and compare presence or absence of RST, FIN, or short server replies. Differences strengthen your conclusion.

# Evidence collection checklist

1. Save the full stdout log from `CVE-2023-21554.py` to a text file  
2. Save the network capture file (for example `msmq_test.pcap`)  
3. Export Application and System events from Event Viewer that correspond to the test time  
4. If available, capture a crash dump of `mqsvc.exe` using procdump and save it for analysis

# Safety and legal notice

This code may cause service crashes and instability on target hosts. Do not run it against systems you do not own or do not have explicit permission to test. Always test in an isolated lab environment and take a VM snapshot before running tests. The original work is credited to the upstream project at:  
https://github.com/leongxudong/MSMQ-Vulnerability

# Attribution

This repository is derived from the original project at:  
https://github.com/leongxudong/MSMQ-Vulnerability

# Contribution

If you add detection helpers or evidence collection scripts please document them and include instructions for safe lab use

# Contact and further reading

Refer to the upstream repository at the link above for original context and binary artifacts. For defensive guidance consult vendor advisories and published writeups about CVE 2023 21554
文件快照

[4.0K] /data/pocs/920de3bcd4805a745d97f4ce3a66d041e9e9aa4c ├── [ 32] connection_parameters.bin ├── [4.5K] CVE-2023-21554.py ├── [ 572] establish_connection.bin ├── [1.0K] LICENSE ├── [6.4K] README.md └── [ 256] user_message.bin 0 directories, 6 files
神龙机器人已为您缓存
备注
    1. 建议优先通过来源进行访问。
    2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
    3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。