176 lines
8.5 KiB
Markdown
176 lines
8.5 KiB
Markdown
# 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](https://securityonline.info/anydesk-exploit-alert-cve-2024-12754-enables-privilege-escalation-poc-available/)
|
||
|
|
- [CVE-2024-52940 IP Exposure](https://www.splashtop.com/blog/lessons-from-anydesk-ip-exposure-vulnerability)
|
||
|
|
- [AnyDesk February 2024 Breach](https://thehackernews.com/search/label/AnyDesk)
|
||
|
|
- [NCC Group: Threat Actors Leveraging AnyDesk](https://www.nccgroup.com/research/the-dark-side-how-threat-actors-leverage-anydesk-for-malicious-activities/)
|
||
|
|
- [AnyDesk CVE List](https://www.cvedetails.com/vulnerability-list/vendor_id-16953/Anydesk.html)
|