300 lines
14 KiB
Markdown
300 lines
14 KiB
Markdown
# AnyDesk — Exploitable Vulnerabilities & Attack Methods
|
|
|
|
## Executive Summary
|
|
|
|
AnyDesk has only 4 publicly known CVEs in recent history — a suspiciously low number for a complex C++ network application handling video codecs, file transfers, clipboard sync, and custom protocol framing. The February 2024 breach (code signing keys + source code stolen) confirms the codebase exists in adversary hands. The attack surface is massive and almost entirely unresearched.
|
|
|
|
---
|
|
|
|
## Known CVEs — Detailed Analysis
|
|
|
|
### CVE-2024-12754 — Symlink/Junction Path Traversal → Local Privilege Escalation to SYSTEM
|
|
|
|
**CVSS:** 5.5 (Medium) — but functionally gives SYSTEM file read
|
|
**Discoverer:** ZDI-24-1711
|
|
**Affected:** AnyDesk < 9.0.1
|
|
**Fixed:** AnyDesk 9.0.1
|
|
|
|
**Technical Details:**
|
|
The AnyDesk service (running as SYSTEM) copies the user's desktop background image to a cache location during session setup. The vulnerability:
|
|
|
|
1. AnyDesk service reads the current user's background image path from registry
|
|
2. Service copies the file to an AnyDesk cache directory
|
|
3. The copy operation runs as NT AUTHORITY\SYSTEM
|
|
4. The service does NOT validate that the source path doesn't traverse through symlinks/junctions
|
|
|
|
**Exploitation:**
|
|
1. Attacker creates a junction point: `C:\Users\<user>\AppData\Roaming\AnyDesk\wallpaper` → `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\CONFIG\`
|
|
2. Sets background image to point to a file in the junction target
|
|
3. AnyDesk service follows the junction (running as SYSTEM) and copies SAM/SYSTEM/SECURITY hive files
|
|
4. Attacker reads the copied hive files from the AnyDesk cache directory
|
|
5. Extract NTLM hashes from SAM + SYSTEM → credential theft → domain compromise
|
|
|
|
**Key Insight for Further Research:**
|
|
- AnyDesk's SYSTEM service performs file operations based on user-controlled paths
|
|
- If there are OTHER file operations the service performs (logs, configs, temp files), the same symlink attack class may apply
|
|
- The service likely also handles file transfer operations — does it validate paths there?
|
|
|
|
---
|
|
|
|
### CVE-2024-52940 — Public IP Disclosure
|
|
|
|
**CVSS:** 7.5
|
|
**Affected:** AnyDesk ≤ 8.1.0
|
|
**Type:** Information disclosure
|
|
|
|
When "Allow Direct Connections" is enabled, AnyDesk leaks the user's public IP address in network traffic. This is lower severity but useful for:
|
|
- Deanonymizing targets behind VPNs
|
|
- Targeting specific IP ranges for network attacks
|
|
- Combining with other vulns for targeted exploitation
|
|
|
|
---
|
|
|
|
### CVE-2025-25065 — SSRF in RSS Feed Parser
|
|
|
|
**Type:** Server-Side Request Forgery
|
|
**Impact:** Internal network access from AnyDesk relay infrastructure
|
|
|
|
The RSS feed parser in AnyDesk can be redirected to make requests to internal endpoints. This targets AnyDesk's infrastructure rather than end-user clients, but demonstrates that input validation is weak across the codebase.
|
|
|
|
---
|
|
|
|
### CVE-2024-45516 — XSS in User Sessions
|
|
|
|
**Type:** Cross-site scripting
|
|
**Impact:** Session injection
|
|
|
|
Limited details available, but demonstrates that AnyDesk's web-facing components have injection vulnerabilities.
|
|
|
|
---
|
|
|
|
## The February 2024 Breach — What Was Stolen
|
|
|
|
**Timeline:**
|
|
- December 2023: Attackers gain access to AnyDesk production systems
|
|
- Mid-January 2024: AnyDesk detects breach during security audit
|
|
- February 2, 2024: Public disclosure
|
|
|
|
**What was compromised:**
|
|
1. **Source code** — Complete AnyDesk source code including DeskRT codec
|
|
2. **Code signing private keys** — Used to sign AnyDesk.exe distributed to all customers
|
|
3. **Production system access** — Full access to build/distribution infrastructure
|
|
|
|
**Impact:**
|
|
- Over 500 samples of Agent Tesla malware signed with the stolen AnyDesk certificate were found on VirusTotal (dating back to June 2022 — the breach may have started earlier)
|
|
- AnyDesk revoked the old certificate and issued new one in version 8.0.8
|
|
- All customer passwords were force-reset
|
|
|
|
**Why this matters for vulnerability research:**
|
|
- The source code is in adversary hands — state actors likely have it
|
|
- If you can obtain or reconstruct the protocol through RE, you can build a fake AnyDesk endpoint
|
|
- The code signing key theft means signed malware could masquerade as legitimate AnyDesk
|
|
- The DeskRT codec source would make fuzzing trivial — but even without it, black-box fuzzing of the binary codec is viable
|
|
|
|
---
|
|
|
|
## Unexplored Attack Surfaces (Original Research Targets)
|
|
|
|
### 1. File Transfer Path Traversal — HIGHEST PROBABILITY
|
|
|
|
**Why this is almost certainly vulnerable:**
|
|
- RDP file transfer has had path traversal FIVE times (2019, 2020, 2025 x3)
|
|
- CVE-2024-12754 proves AnyDesk has path validation issues
|
|
- File transfer is a common, complex feature that handles user-controlled filenames
|
|
- AnyDesk supports both file manager transfers AND drag-and-drop — two code paths to test
|
|
|
|
**Attack scenario:**
|
|
1. Victim connects to attacker's AnyDesk instance (or attacker connects to victim and has file transfer permission)
|
|
2. Attacker initiates file transfer with filename: `..\..\..\..\Users\<victim>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\payload.bat`
|
|
3. If AnyDesk's receiving side doesn't validate the filename, the file lands in the Startup folder
|
|
4. Next login → payload executes → RCE
|
|
|
|
**Testing approach:**
|
|
1. Set up two AnyDesk instances on separate VMs
|
|
2. Capture file transfer traffic with Wireshark (TCP port 6568)
|
|
3. Identify the protocol message that carries filenames
|
|
4. Use a TCP proxy to modify the filename in transit (add ../ sequences)
|
|
5. Test both the file manager and drag-and-drop transfer paths
|
|
6. Test with: backslashes, forward slashes, Unicode path separators, null bytes, double encoding
|
|
7. Monitor the receiving side's filesystem to see where the file lands
|
|
|
|
**Alternative approach (faster):**
|
|
1. Attach x64dbg to receiving AnyDesk instance
|
|
2. Set breakpoints on CreateFileW, WriteFile, MoveFileW
|
|
3. Initiate a normal file transfer
|
|
4. Trace the call stack to find where filenames are processed
|
|
5. Look for validation (or lack thereof) in the filename handling code
|
|
6. If no validation exists → path traversal confirmed
|
|
|
|
---
|
|
|
|
### 2. DeskRT Codec — RCE via Malformed Frames
|
|
|
|
**What DeskRT is:**
|
|
- Proprietary video codec designed for screen content (not natural video)
|
|
- Optimized for text, UI elements, low-latency (<16ms)
|
|
- Up to 60 FPS
|
|
- Handles keyframes and delta frames
|
|
- Tile/block-based decomposition
|
|
- Color space conversion
|
|
|
|
**Why it's vulnerable:**
|
|
- Fully proprietary — zero public security audits
|
|
- Complex binary format with decompression algorithms
|
|
- Header fields control memory allocation sizes (width, height, stride, tile count, compressed size)
|
|
- Same bug class as CVE-2025-29966 (RDP bitmap heap overflow): malicious server sends crafted frame → client allocates undersized buffer → heap overflow
|
|
- DeskRT is highly optimized for performance — optimization routinely sacrifices bounds checking
|
|
|
|
**Attack scenario:**
|
|
1. Build a fake AnyDesk endpoint (or modify traffic via TCP proxy)
|
|
2. Send DeskRT frames with manipulated header fields:
|
|
- Width/height that cause integer overflow in `width * height * bytes_per_pixel`
|
|
- Compressed size field that doesn't match actual data
|
|
- Tile count that exceeds allocated array
|
|
- Delta frame referencing non-existent keyframe regions
|
|
3. Client's DeskRT decoder processes the malformed frame
|
|
4. Integer overflow → small allocation, large copy → heap overflow
|
|
5. Heap overflow → arbitrary code execution
|
|
|
|
**Research approach:**
|
|
1. Capture legitimate DeskRT frames between two AnyDesk instances
|
|
2. Identify frame header format: magic bytes, version, width, height, tile info, compression type
|
|
3. RE the decoder functions in AnyDesk.exe (search for decompression loops, alloc patterns)
|
|
4. Build a Python proxy that modifies DeskRT frames in transit
|
|
5. Systematic fuzzing: mutate each header field while monitoring for crashes
|
|
6. Use PageHeap + GFlags for enhanced heap corruption detection
|
|
|
|
---
|
|
|
|
### 3. Clipboard Injection
|
|
|
|
**Attack surface:**
|
|
- AnyDesk syncs clipboard bidirectionally
|
|
- Clipboard can carry: text, rich text, images, files
|
|
- File clipboard operations use descriptors with filenames (similar to RDP's FileGroupDescriptorW)
|
|
- Image clipboard data requires format-specific decoding
|
|
|
|
**Path traversal via clipboard file paste:**
|
|
1. Copy a file on the attacker side
|
|
2. AnyDesk sends clipboard sync message to victim
|
|
3. If the file descriptor carries an unsanitized filename → path traversal on paste
|
|
4. Same attack as CVE-2019-0887 but in AnyDesk instead of RDP
|
|
|
|
**Image clipboard overflow:**
|
|
1. Copy a crafted image to clipboard on attacker side
|
|
2. AnyDesk sends bitmap/image data to victim
|
|
3. If width/height/bpp fields are server-controlled and not validated → heap overflow on decode
|
|
|
|
---
|
|
|
|
### 4. Auto-Update MITM
|
|
|
|
**The 2024 breach context:**
|
|
- AnyDesk's code signing keys were stolen
|
|
- They issued new certificates, but the UPDATE MECHANISM itself may be weak
|
|
|
|
**Research questions:**
|
|
1. Does AnyDesk use certificate pinning for update checks?
|
|
2. What URL does it check? Is it HTTPS-only or does it fall back to HTTP?
|
|
3. Is the update binary signature-verified before execution?
|
|
4. Can a DNS hijack + self-signed cert serve a malicious update?
|
|
5. Does the update run as SYSTEM (since AnyDesk service runs as SYSTEM)?
|
|
|
|
**If no cert pinning:**
|
|
- MITM the update check → serve malicious AnyDesk.exe
|
|
- If signed with the stolen (now-revoked) cert, older clients may still accept it
|
|
- Update runs as SYSTEM → instant SYSTEM-level code execution
|
|
|
|
---
|
|
|
|
### 5. Protocol Framing Attacks
|
|
|
|
**AnyDesk's custom protocol:**
|
|
- Not RDP — entirely proprietary
|
|
- TLS 1.2 with RSA 2048 key exchange
|
|
- AES-256 for session encryption
|
|
- TCP primary (port 6568 direct, 80/443 via relay)
|
|
- Message types for: video, audio, file transfer, clipboard, control, input
|
|
|
|
**Fuzzing approach:**
|
|
1. Capture raw TCP traffic (pre-TLS if possible, or instrument AnyDesk to log plaintext)
|
|
2. Identify TLV or length-prefixed framing structure
|
|
3. Map all message type IDs
|
|
4. Build a protocol-aware fuzzer that mutates:
|
|
- Message type field (send unexpected types)
|
|
- Length fields (undersized, oversized, zero, 0xFFFFFFFF)
|
|
- Out-of-order messages (data before handshake)
|
|
- Compressed message bodies with bad decompression params
|
|
|
|
---
|
|
|
|
## AnyDesk as a "Malicious Server" (Equivalent to Rogue RDP)
|
|
|
|
### Can you RAT someone connecting to your AnyDesk?
|
|
|
|
**Short answer:** Yes, but differently from RDP.
|
|
|
|
**AnyDesk permissions model:**
|
|
When someone connects to your AnyDesk instance, YOU control what they can do. But when YOU connect to someone else, they can grant you permissions. The attack vectors depend on the direction:
|
|
|
|
**Scenario A: Victim connects to attacker's AnyDesk**
|
|
- Attacker has full control of what the victim sees (screen content)
|
|
- If file transfer is enabled: attacker can SEND files to victim with potentially traversal paths
|
|
- If clipboard sync is enabled: attacker can inject clipboard content
|
|
- The DeskRT video stream to the victim is fully attacker-controlled → codec exploitation
|
|
|
|
**Scenario B: Attacker connects to victim (with permissions)**
|
|
- If victim grants file transfer: attacker can upload files to victim with path traversal
|
|
- If victim grants clipboard: attacker can inject clipboard content
|
|
- This is less interesting because it requires victim to grant permissions
|
|
|
|
**The most interesting scenario is A** — victim connecting to attacker, because:
|
|
- The attacker controls the DeskRT stream (codec exploitation)
|
|
- The attacker controls clipboard responses
|
|
- The attacker controls file transfer responses
|
|
- This mirrors the "rogue RDP server" attack model
|
|
|
|
---
|
|
|
|
## Priority Research Roadmap
|
|
|
|
| # | Target | Bug Class | Difficulty | Probability | Impact |
|
|
|---|--------|-----------|------------|-------------|--------|
|
|
| 1 | File transfer path traversal | Path traversal | Low-Medium | Very High | Arbitrary file write → RCE |
|
|
| 2 | DeskRT codec fuzzing | Heap overflow / integer overflow | Medium-High | High | RCE (client-side) |
|
|
| 3 | Clipboard file paste traversal | Path traversal | Medium | High | Arbitrary file write → RCE |
|
|
| 4 | Clipboard image overflow | Heap overflow | Medium | Medium-High | RCE |
|
|
| 5 | Auto-update MITM | Signature bypass | Low-Medium | Medium | RCE as SYSTEM |
|
|
| 6 | Protocol framing | Various | Medium | Medium | Crash → potential RCE |
|
|
| 7 | SYSTEM service file ops (CVE-2024-12754 variants) | Symlink/junction | Low | High | Local privesc to SYSTEM |
|
|
|
|
---
|
|
|
|
## Tools Needed
|
|
|
|
| Tool | Purpose |
|
|
|------|---------|
|
|
| Two Windows VMs | Testing AnyDesk connections |
|
|
| Wireshark | Protocol capture on port 6568 |
|
|
| mitmproxy or custom TCP proxy | Modify AnyDesk traffic in transit |
|
|
| IDA Pro / Ghidra | RE AnyDesk.exe (DeskRT decoder, file transfer handler) |
|
|
| x64dbg | Dynamic analysis, breakpoints on file/memory operations |
|
|
| WinAFL or libFuzzer | Coverage-guided fuzzing of DeskRT decoder |
|
|
| Python | Custom protocol replay / fake AnyDesk endpoint |
|
|
| GFlags / PageHeap | Enhanced heap corruption detection |
|
|
| Process Monitor | File system monitoring during file transfer |
|
|
|
|
---
|
|
|
|
## References
|
|
|
|
- [CVE-2024-12754 PoC — AnyDesk Privilege Escalation](https://gbhackers.com/hackers-exploit-anydesk-vulnerability/)
|
|
- [CVE-2024-12754 Detailed Analysis](https://medium.com/@abdulmoeezsiddiqui4/anydesk-vulnerability-cve-2024-12754-1bfd702216d6)
|
|
- [AnyDesk February 2024 Breach — Akamai Analysis](https://www.akamai.com/blog/security-research/anydesk-breach-what-to-know-mitigations-and-recommendations)
|
|
- [Huntress: AnyDesk Stolen Code Signing Certificate](https://www.huntress.com/blog/threat-advisory-possible-anydesk-stolen-code-signing-certificate)
|
|
- [AnyDesk Breach — Cybereason Aftermath Analysis](https://www.cybereason.com/blog/threat-alert-the-anydesk-breach-aftermath)
|
|
- [TechCrunch: AnyDesk Password Reset and Cert Revocation](https://techcrunch.com/2024/02/05/remote-access-giant-anydesk-resets-passwords-and-revokes-certificates-after-hack/)
|
|
- [Synacktiv: Forensic Analysis of Remote Access Tools](https://www.synacktiv.com/en/publications/legitimate-rats-a-comprehensive-forensic-analysis-of-the-usual-suspects)
|
|
- [AnyDesk CVE List (CVEDetails)](https://www.cvedetails.com/vulnerability-list/vendor_id-16953/Anydesk.html)
|
|
- [CVE-2024-52940: AnyDesk IP Exposure](https://www.vicarius.io/vsociety/posts/cve-2024-52940-mitigation-anydesk-vulnerability)
|