GitHub Security Advisory: GHSA-q8j9-34qf-7vq7
Package: github.com/bishopfox/sliver (GO)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: <= 1.5.43
Patched in: 1.5.44

Summary: Silver has unrestricted traffic between Wireguard clients

Details:
### Summary
Sliver's custom Wireguard netstack doesn't limit traffic between Wireguard clients, this could lead to:
1. Leaked/recovered keypair (from a beacon) being used to attack operators.
2. Port forwardings usable from other implants.


### Details
1. Sliver treat operators' Wireguard config and beacon/session's Wireguard config equally, they both connect to the wireguard listener created from the CLI.

2. The current netstack implementation does not filter traffic between clients. 
I think this piece of code handle traffic between clients, from experimental results clients can ping and connect to each other freely, and I didn't see any filtering here either:
```
File: server\c2\wireguard.go
246: func socketWGWriteEnvelope(connection net.Conn, envelope *sliverpb.Envelope) error {
247: 	data, err := proto.Marshal(envelope)
248: 	if err != nil {
249: 		wgLog.Errorf("Envelope marshaling error: %v", err)
250: 		return err
251: 	}
252: 	dataLengthBuf := new(bytes.Buffer)
253: 	binary.Write(dataLengthBuf, binary.LittleEndian, uint32(len(data)))
254: 	connection.Write(dataLengthBuf.Bytes())
255: 	connection.Write(data)
256: 	return nil
257: }
258: 

```
3. The docs says to use a Wireguard clients and operator wg-config to connect to the same WG listener as beacons:
https://sliver.sh/docs?name=Port%20Forwarding

4. If the operator uses official wireguard clients that integrates with the OS's netstack (I'm using the [Windows client](https://www.wireguard.com/install/)) then their services are accessible on the wireguard interface's IP address (for example 100.64.0.3) when the services listen on 0.0.0.0 (SSH, RDP, SMB, etc) 
![image](https://github.com/user-attachments/assets/8c791655-6f77-423c-8274-389e0850436b)

5. The beacon's wireguard private key can be recovered through a process dump or other forensic techniques.
6. When a private key is recovered, an attacker can connect to 100.64.0.1:1337 (key exchange listener) to generate new wireguard clients without the operators' knowledge, in that way achieve persistence inside the wireguard network.


### PoC
Easy way:
1. Create 2 operators wireguard config.
2. Connect them both to the wireguard listener.
3. From one machine, ping/scan/connect to the other's services like RDP (3389), SSH (22), etc.

Slightly complicated way:
1. From the operator's machine, connect to the wireguard listener.
2. On the attacker's machine, run a beacon.
3. Dump the process
4. Find the private key, public key, endpoint, etc in the dump file:
![image](https://github.com/user-attachments/assets/84d3841f-398d-4bca-939f-bf8ed2881be7)
![image](https://github.com/user-attachments/assets/000c7d02-b6f0-4b12-82e5-29eddfff93f8)
![image](https://github.com/user-attachments/assets/3d0a3e80-3a16-4434-8622-1832c5865a85)
![image](https://github.com/user-attachments/assets/a17f73ab-622b-4852-9c15-0ad5c5afa0eb)

5. Construct a valid Wireguard config based on the strings found. On the attacker's machine, connect to the Wireguard listener.
6