cloudshellproxy v0.5.11

CloudShell Proxy

CloudShell based TCP proxy.

Introduction

Nowadays, most cloud computing services provide web-based Shell to manage servers, known as CloudShell.

For stability and security, the CloudShell traffic is routed through the vendor's internal network, rather than a direct connection between the browser and the server.

Using this feature, arbitrary data can be wrapped into CloudShell traffic and communicate with the server over the vendor's internal network for a high-quality or covert channel.

Architecture

There are 3 parts in this project:

• browser side (inject.js)

• client side (proxy-client)

• server side (proxy-server)

Supported Vendors

This idea theoretically supports all CloudShells, but in order to improve performance and stability, each vendor's CloudShell needs to be adapted.

Install

Run on both the client and server:

npm install -g cloudshellproxy

Since C++ addons are used, the system requires a C++ compiler and Python.

If the server-side Node.js is not global (e.g. installed via nvm), this program must be installed in the CloudShell user environment.

Update

This project will be continuously updated. It is recommended to use the latest version for both client and server side:

npm update -g cloudshellproxy

Usage

Client:

cloudshellproxy client --help

The subcommand client is default and can be omitted.

Server:

cloudshellproxy server --help

The server-side commands are entered automatically and are rarely entered manually.

Demo

Map a local port (2022) to the server port (22):

cloudshellproxy 2022 22

Log in to the CloudShell, open the browser console and run:

import('http://127.0.0.1:10000/inject.js')

The injected js will connect to the proxy-client, send a command to the CloudShell to start the proxy-server, and then bridge the two streams.

Now, connecting to local port 2022 is equivalent to connecting to server port 22.

ssh 127.0.0.1 -p2022

▶️ ssh example

Note

Some CloudShells run in a frame page, so the code needs to be injected into the corresponding context. For example, right-click on the terminal UI and select Inspect, the console will switch to its context.

Do not run background jobs on the server to prevent unexpected stdout/stderr output from interrupting communication.

Tip

This program only supports a single connection, if you need more connections, you can use other proxy tools based on this connection.

For example, using the SSH directly:

ssh 127.0.0.1 -p2022 -D12345

In this way, a SOCKS5 service can be created on the local port 12345.

Automation

CloudShell sessions are short-lived and expire after a few hours, so you need to log back in frequently and re-inject code, which can be tedious.

You can consider using automation tools such as WebDriver, puppeteer, playwright, etc., or some browser extensions.

Encoding

Many CloudShells use text format (UTF-8) to communicate with the backend, while our data is binary, so choosing a appropriate encoding can improve transmission efficiency.

Let's review the UTF-8 encoding first:

https://en.wikipedia.org/wiki/UTF-8#Encoding

Obviously, using the 0, 127 range is the most cost-effective, with only 1/8 of the overhead and an efficiency of 87.5%.

However, most CloudShells are not suitable for base128 encoding. For example, some CloudShells communicate in JSON format, which causes special characters to be escaped:

This will lose a lot of efficiency, even worse than base64.

Excluding these characters, there are 94 characters in the 0, 127 range that will not be escaped, so base94 is better.

base94: log2(94) / 8 ≈ 82%
base64: log2(64) / 8 = 75%

By testing the CloudShell which using JSON communication, base94 has higher bandwidth than base64:

If the CloudShell supports compression, e.g. its WebSocket service enables the deflate extension, the efficiency will be different. In this case, base64 is usually better than base94, because the redundancy of base64 is more obvious and easier to compress.

In practice, base94 cannot achieve the theoretical efficiency, because modulo and division operations are very expensive for large numbers.

We need to trade space for time. Instead of treating the entire data as a large number, we choose parts of bytes as numbers, usually within 16 bytes.

The following code can display the binary / string length and efficiency ratio of baseN:

function baseN(n) {
  const MAX_RATIO = Math.log2(n) / 8
  const result = []

  for (let strLen = 1; strLen < 16; strLen++) {
    const binLen = Math.floor(strLen * MAX_RATIO)
    result.push({
      binLen,
      strLen,
      ratio: binLen / strLen,
    })
  }
  result.sort((a, b) => b.ratio - a.ratio)
  console.table(result)
}
baseN(94)

For base94, a 9-byte binary / 11-byte string is the best practice for space and performance balance, only losing 0.1% efficiency.

This project supports the following encodings:

The client will use a pre-configured encoding according to different vendors. You can also override the default encoding with the -e/--encoding option, and customize the code table with the -t/--table option. For example, using a reversed base64 code table:

cloudshellproxy 2022 22 \
  -e base64 \
  -t '=/+9876543210zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA'

Note: The code table for base64 has 65 characters, as the last one is used for length padding. In the above case, A is used as padding.

Show stdout

By default, the stdout data in CloudShell will be blocked, keeping the screen clean and saving system resources.

If you want to display the stdout data, just run the following code in the CloudShell page:

window.CLOUDSHELL_SHOW_STDOUT = true

Now, all received data will be displayed in CloudShell:

▶️ show stdout

It's like dial-up internet decades ago — where information was encoded into sound signals and transmitted over the telephone — now information is encoded into base64 strings and transmitted over the CloudShell.

FAQ

A: How can I determine my CloudShell's maximum transfer speed?

Q: You can run cat /dev/zero or cat /dev/random in CloudShell to generate a lot of data, and then watch the incoming traffic in task manager.

A: Why is the data transfer incorrect?

Q: Make sure the client and server are the same version:

cloudshellproxy --version

The encoding implementation may be changed, resulting in data errors.

In addition, the cloud vendor may change the transfer protocol at any time, if this program is not adapted in time, it may not work.

A: Why does the installation fail in some free CloudShells?

Q: It may be a permission problem, or the version of Node.js is too low. You can try to run the following commands to create a new user and update the Node.js version:

adduser --gecos "" --disabled-password test
su - test

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm

nvm install v16.20.0
npm install -g cloudshellproxy

Warning

This tool is for learning and experimentation only, do not overuse it, or do so at your own risk.

License

MIT