anydeskrce-something/01-attack-surface.md

AnyDesk Attack Surface Analysis

Architecture

• Binary: AnyDesk.exe (~30-40MB, C++, not packed, standard PE)
• Protocol: Custom proprietary (NOT RDP)
• Codec: DeskRT — proprietary video codec designed for screen capture, low-latency
• Transport: TCP (primary port 6568 for direct, or relay via AnyDesk servers on 80/443)
• Encryption: TLS 1.2 with RSA 2048 key exchange, AES-256 for session data
• Platform: Windows, macOS, Linux, Android, iOS

Known CVEs (Sparse — Under-Researched Target)

CVE	Year	Type	Impact	Details
CVE-2024-12754	2024	Path traversal / symlink	Local privesc to SYSTEM	Background image copy runs as SYSTEM. Symlink junction → read SAM/SYSTEM/SECURITY hives. PoC published. Fixed in 9.0.1
CVE-2024-52940	2024	Info disclosure	Public IP exposure	"Allow Direct Connections" leaks public IP. Affects ≤8.1.0
CVE-2025-25065	2025	SSRF	Internal network access	RSS feed parser allows redirecting requests to internal endpoints
CVE-2024-45516	2024	XSS	Session injection	Cross-site scripting in user sessions

Key observation: Only 4 CVEs in recent history. Compare to RDP's 7 RCEs in 18 months. This means either AnyDesk is incredibly secure (unlikely for a complex C++ network application) or nobody is looking hard enough (much more likely).

Attack Surface Map

1. DeskRT Codec (HIGHEST VALUE — RCE TARGET)

What it is: Proprietary video codec for encoding/decoding screen content. Designed for computer graphics (not video), optimized for text/UI rendering with low latency.

Attack surface:

• Frame decompression in the client
• Keyframe vs delta frame parsing
• Color space conversion
• Resolution/scaling calculations (integer overflow potential)
• Tile/block decomposition

Why it's promising:

• Fully proprietary — zero public security audits
• Complex binary parsing (decompression algorithms)
• Same bug class as RDP bitmap overflow (CVE-2025-29966): malicious server sends oversized/malformed frame → heap overflow in client
• DeskRT is the core of AnyDesk's value proposition, meaning it's complex and highly optimized (optimization often introduces bounds-checking gaps)

Approach:

1. Capture DeskRT frames between two AnyDesk instances (Wireshark/raw TCP capture)
2. Identify frame boundaries and header format
3. RE the decoder in AnyDesk.exe (look for decompression loops, memory allocation based on header fields)
4. Build a fake AnyDesk server that sends malformed DeskRT frames
5. Fuzz frame headers: width, height, stride, tile count, compressed size fields
6. Monitor for crashes (heap overflow, integer overflow, OOB read/write)

2. File Transfer (HIGHEST PROBABILITY — PATH TRAVERSAL)

What it is: AnyDesk has built-in file transfer (file manager + drag-and-drop).

Attack surface:

• Filename handling when receiving files from remote side
• Destination path construction
• Character encoding (UTF-8/UTF-16 filename handling)
• Symbolic link / junction following
• File size validation
• Metadata transfer (timestamps, attributes)

Why it's promising:

• Path traversal in file transfer has been found in RDP FOUR separate times (2019, 2020, 2025 x2)
• CVE-2024-12754 shows AnyDesk already has path handling issues (symlink/junction following)
• File transfer in remote desktop software is a consistently vulnerable feature
• If the receiving client doesn't sanitize ..\..\ or ../ in filenames from the remote side, you get arbitrary file write

Approach:

1. Set up two AnyDesk instances
2. Initiate file transfer, capture the protocol
3. RE the filename parsing in the receiving client
4. Test: send a file with name ..\..\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\payload.bat
5. Test: send a file with name using forward slashes ../../
6. Test: Unicode path separators, null bytes, double encoding
7. If path traversal works → arbitrary file write → Startup folder → code execution

3. Clipboard Sync

What it is: Bidirectional clipboard sharing between connected machines.

Attack surface:

• Clipboard format parsing (text, rich text, images, files)
• File copy/paste operations (FileGroupDescriptor equivalent)
• Image format parsing (bitmap data from clipboard)
• Large clipboard data handling (buffer allocation)

Why it's promising:

• Same attack surface that produced CVE-2019-0887 in RDP
• If AnyDesk supports file copy/paste via clipboard, the filename in the file descriptor is server-controlled input
• Image clipboard data requires decoding — potential for heap overflow

Approach:

1. Copy a file on the remote side, paste on the local side
2. Capture the clipboard protocol messages
3. RE the file descriptor format
4. Inject path traversal in the filename
5. Test image clipboard with oversized/malformed bitmap data

4. Auto-Update Mechanism

What it is: AnyDesk checks for and downloads updates automatically.

Attack surface:

• Update check URL — is it HTTPS with cert pinning?
• Download verification — signature check, hash verification
• Update extraction — temp directory, file permissions
• Update execution — does the new binary get verified before launch?

Why it's promising:

• If there's no cert pinning, a MITM (or DNS hijack) can serve a malicious update
• If signature verification is weak or bypassable, the update binary can be replaced
• The update runs with whatever privilege AnyDesk has (often SYSTEM if installed as service)
• CVE-2024-12754 showed AnyDesk's SYSTEM-level file operations are exploitable

Approach:

1. Monitor AnyDesk's update check (Wireshark + DNS capture)
2. Identify the update URL and certificate chain
3. Attempt MITM with a self-signed cert (test for cert pinning)
4. If pinned: look for pinning bypass (older TLS, fallback URLs)
5. If not pinned: serve a modified binary, check if it's accepted
6. Examine signature verification code in AnyDesk.exe

5. Protocol Framing / Handshake

What it is: The custom protocol that wraps all AnyDesk communication.

Attack surface:

• Message type/length fields — integer overflow in length parsing
• Handshake/authentication — can a malicious server send unexpected responses?
• Channel multiplexing — can you send data on unexpected channels?
• Compression — if messages are compressed, decompression bugs

Approach:

1. Capture raw TCP traffic between two instances
2. Identify the framing format (TLV? length-prefixed? delimiter?)
3. Map all message types
4. Build a fake server that sends malformed messages
5. Fuzz length fields, type fields, out-of-order messages

Research Priority

Target	Difficulty	Probability	Impact	Priority
File transfer path traversal	Low-Medium	Very High	High (arbitrary file write)	1
DeskRT codec fuzzing	Medium-High	High	Critical (heap overflow → RCE)	2
Clipboard file paste	Medium	High	High (arbitrary file write)	3
Auto-update MITM	Low-Medium	Medium	Critical (RCE as SYSTEM)	4
Protocol framing	Medium	Medium	Variable	5

Setup Requirements

1. Two Windows VMs (or one VM + host)
2. AnyDesk installed on both (free version works)
3. Wireshark with TCP stream capture
4. IDA Pro or Ghidra for RE of AnyDesk.exe
5. x64dbg attached to AnyDesk for dynamic analysis
6. Python for building fake server / protocol replayer

Key Files to RE

File	What to Look For
AnyDesk.exe	Main binary — all protocol handling, codec, file transfer
*.dll in AnyDesk install dir	Any helper DLLs (crypto, codec, etc.)
%ProgramData%\AnyDesk\	Config files, logs, connection data
%AppData%\AnyDesk\	User-level config
ad.trace / connection_trace.txt	Debug logs with protocol info

References

• CVE-2024-12754 PoC and Analysis
• CVE-2024-52940 IP Exposure
• AnyDesk February 2024 Breach
• NCC Group: Threat Actors Leveraging AnyDesk
• AnyDesk CVE List