Using Trust Maintenance Tunnelling Protocol

Using Trust Maintenance Tunneling is a general and intentionally vague protocol for specifying how one might establish transport tunnels using trusted duplex mediums.

Required parties for UTMT:

• A controlpane server cluster with at least one server and a singular controller with communication established between all servers in the cluster and the controller itself. "Communication established" is intentionally vague.
• At least one agent client
• At least one trusted duplex between the agent and the cluster

A trusted duplex is defined as any duplex data stream that you are authorized for and trusted to use. An implementation of UTMT may restrict the allowed set of trusted duplexes to a specific set. What and which duplexes are allowed is intentionally vague.

Required steps for establishing a UTMT tunnel:

1. A connection is established between the agent and the cluster over a trusted duplex. How this connection is formed is intentionally vague.
2. By default, the agent and the connected server within the cluster must establish authentication, however this can be opted out, and how authentication is established is intentionally vague.
3. An agent is identified by its key. One agent may only have one key. How the agent is identified in codespace, userspace, or cli-space is free of choice—implementers may assign names and aliases to an agent, but the key is the agent's real identity. The format and length of keys and identifiers is intentionally vague; implementers may choose UUIDs, ed25519 keys, or any other scheme, with one constraint: all keys and identifiers must be UTF-8 encoded. On the first established connection between the agent and the cluster, the agent presents its key, and the controller must provide the agent with a manifest (typically via the connected server) containing at minimum a unique identifier for the aggregate. This identifier is for the aggregate, not the agent—it is used when establishing secondary duplexes for aggregation into a larger singular duplex called the aggregate. The manifest may optionally contain advertisements for other ways to connect with the cluster and widen the aggregate. A single agent, as identified by its key, may have more than one client on the same host or even across multiple hosts to form its aggregate, though spreading across hosts is likely impractical. On connection finality of the aggregate, the aggregate identifier may be discarded. What constitutes connection finality is intentionally vague—it may be any connection drop, only intentional disconnects, intentional disconnects combined with timed-out interrupts, or any other definition the implementer chooses. In such case, before a new aggregate can be established, the agent must be issued a new aggregate identifier. The initial issuance of the manifest may occur ahead of time. Re-issuance or rerequest of the manifest may occur at any time prior to the establishment of aggregate channels or any time later on the aggregate's control channel.
4. Once the agent has been issued an aggregate identifier, the agent and the cluster may recycle the first duplex and/or establish secondary duplexes with that identifier to build its aggregate. A single-duplex aggregate is permitted. In a multi-server setup, this aggregation may require shareable sockets.
5. Once an aggregate is established, a multiplexer is applied to each duplex establishing the aggregate's initial channel set. At least one control channel is required across the entire aggregate. More than one is not mandatory, but not prohibited. Handling of a complete loss of control channel is intentionally vague and up to the implementer. Additions or removals of duplexes from the aggregate may occur at any time. Load balancing across the channel set must be handled intelligently either internally by applicable server on the aggregate and/or by the controller.
6. Once an aggregate's channel set is established, the aggregate may start forwarding orders from the controller to the agent over control channel or directly to servers on the aggregate. These orders may contain instructions to:

• bind and listen to transport ports and forward transport packets to an aggregate channel or
• forward transport packets from a specific channel to a specified destination. Each server and agent is permitted to deny any order without reason, but is not permitted to change the order. Orders to the aggregate may also contain instructions for the aggregate's servers to establish connections with other servers on other aggregates on the same UTMT cluster. This is to establishing agent-to-agent forwarding.

Abusing Trust Tunnelling (ATT) Protocol

Due to the vague nature of UTMT and some of its early implementations, it is well understood that it can easily be abused. Therefore a second protocol whose sole difference is intent is defined. Notice the lack of the word "maintenance." Establishing a maintenance tunnel over a trusted duplex, while benevolent in intent, in abuse or circumvention of trust is still simply an abuse of trust, and therefore the only qualifier that actually matters. Any implementation of UTMT over an abuse or circumvention of trust is an implementation of ATT.

Because UTMT and ATT can be established over any trusted duplex, it is important for any security researcher or analyst to identify all trusted duplexes on their IT infrastructure. Some examples of trusted duplexes not thought of for being used for tunnelling can include:

• The clipboard
• Files
• Shared memory
• HTTPS protocols--particularly Websockets, WebTransport and SSE (with some kind of adapter to establish duplex)

The above trusted duplexes were picked intentionally to highlight why ATT is a problem and was defined.

A vendor seeking to establish a maintenance tunnel to an on-prem service technically has no physical blocker if general HTTPS traffic is permitted between the on-prem box and the vendor's datacenter, circumventing any SSH or VPN tunnelling approval processes.

This also means attackers have an incredibly wide way to facilitate attacks or exfiltrate data if they can penetrate into a trusted duplex.

This problem is a mixed bag. Because while it does come with the above security problems, it also does come with security benefits. One such benefit is that since UTMT can occur over HTTPS, you don't technically need to install anything to use it. You could put an agent client script in an enduser's clipboard with an authentication key, paste it, and then close the encompassing script engine when you are done tunnelling and both the agent and the key are automatically cleaned up. At-rest risks are entirely mitigated and there is technically no risk of reuse of an at-rest agent and/or key.

However, the above benefit does also mean attackers using ATT can perform attacks without leaving any trace.