Privacy tools-seller Windscribe said it failed to encrypt company VPN servers that were recently confiscated by authorities in Ukraine, a lapse that made it possible for the authorities to impersonate Windscribe servers and capture and decrypt traffic passing through them.
The Ontario, Canada-based company said earlier this month that two servers hosted in Ukraine were seized as part of an investigation into activity that had occurred a year earlier. The servers, which ran the OpenVPN virtual private network software, were also configured to use a setting that was deprecated in 2018 after security research revealed vulnerabilities that could allow adversaries to decrypt data.
“On the disk of those two servers was an OpenVPN server certificate and its private key,” a Windscribe representative wrote in the July 8 post. “Although we have encrypted servers in high-sensitivity regions, the servers in question were running a legacy stack and were not encrypted. We are currently enacting our plan to address this.”
Windscribe’s admission underscores the risks posed by an explosion of VPN services in recent years, many from businesses few people have heard of before. People use VPNs to funnel all their Internet traffic into an encrypted tunnel, to prevent people connected to the same network from being able to read or tamper with data or to detect the IP addresses of the two parties communicating. The VPN service then decrypts the traffic and sends it to its final destination.
By failing to follow standard industry practices, Windscribe largely negated those security guarantees. While the company attempted to play down the impact by laying out the requirements an attacker would have to satisfy to be successful, those conditions are precisely the ones VPNs are designed to protect against. Specifically, Windscribe said, the conditions and the potential consequences are:
- The attacker has control over your network and can intercept all communications (privileged position for MITM attack)
- You are using a legacy DNS resolver (legacy DNS traffic is unencrypted and subject to MITM)
- The attacker has the ability to manipulate your unencrypted DNS queries (the DNS entries used to pick an IP address of one of our servers)
- You are NOT using our Windscribe applications (our apps connect via IP and not DNS entries)
The potential impact for the user if all of the above conditions are true:
- An attacker would be able to see unencrypted traffic inside of your VPN tunnel
- Encrypted conversations like HTTPS web traffic or encrypted messaging services would not be affected
- An attacker would be able to see the source and destinations of traffic
It’s important to remember that:
- Most internet traffic is encrypted (HTTPS) inside of your VPN tunnel
- No historical traffic is at risk thanks to PFS (perfect forward secrecy) which prevents decryption of historical traffic, even if one possesses the private key for a server
- No other protocols supported by our servers are affected, only OpenVPN
Three years late
Besides the lack of encryption, the company also uses data compression to improve network performance. Research presented at the 2018 Black Hat security conference in Las Vegas disclosed an attack known as Voracle, which uses clues left behind in compression to decrypt data protected by OpenVPN-based VPNs. A few months later, OpenVPN deprecated the feature.
The privacy tools-maker said it’s in the process of overhauling its VPN offering to provide better security. Changes include:
- Discontinuing use of its current OpenVPN certificate authority in favor of a new one that “follows industry best practices, including the use of an intermediate certificate authority (CA)”
- Transitioning all servers to operate as in-memory servers with no hard disk backing. This means that any data the machines contain or generate live solely in RAM and can’t be accessed once a machine has been shut off or rebooted
- Implementing a forked version of Wireguard as the primary VPN protocol
- Deploying “resilient authentication backend” to allow VPN servers to function even if there is a complete outage of core infrastructure
- Enabling new application features, such as the ability to change IP addresses without disconnecting, request a specific and static IP, and “multi-hop, client side R.O.B.E.R.T. rules that are not stored in any database”
In an email, Windscribe Director Yegor Sak expanded on the steps his company is taking. They include:
1. All keys required for server function are no longer stored permanently on any of our servers and exist solely in memory after they are put into operation
2. All servers have unique short-lived certificates and keys generated from our new CA which are rotated
3. Each server certificate has uniquely identifying Common Name + SANs
4. New OpenVPN client configurations enforce server certificate X509 name verification using the common name which is unique.
He was unusually candid about the lapse, writing:
In the meantime, we make no excuses for this omission. Security measures that should have been in place were not. After conducting a threat assessment we feel that the way this was handled and described in our article was the best move forward. It affected the fewest users possible while transparently addressing the unlikely hypothetical scenario that results from the seizure. No user data was or is at risk (the attack vector to make use of the keys requires the attacker to have full control over the victim’s network with several prerequisites outlined in the above article). The hypothetical situations outlined are no longer exploitable because the final CA sunset process was already completed last week on July 20th.
It’s not clear how many active users the service has. The company’s Android app, however, lists more than 5 million installs, an indication that the user base is likely large.
The seizure of the Windscribe servers underscores the importance of the kind of basic VPN security hygiene that the company failed to follow. That, in turn, emphasizes the risks posed when people rely on little-known or untested services to shield their Internet use from prying eyes.
- Hi folks, Yegor from Windscribe here. Addressing some comments above:Entegy wrote:Why would forking Wireguard be preferable to just implementing it in their stack? Without proper maintenance (which faith that the company would do so right now) wouldn’t that mean their fork could deviate wildly from what’s expected from a Wire guard implementation?
There are several reasons for this, mainly the ability to fetch keys from a central place without having every single user’s config be deployed on every server (already implemented), as well as negotiating the interface address during the handshake to eliminate the need for static interface addresses (work in progress). Wireguard was never designed for millions of users scale, which is why these changes are required. This can be achieved “out of band”, but it’s clunky. More details here: https://blog.windscribe.com/introducing … a1670700a6Ushio wrote:show nested quotesSuinusLatinus wrote:You had one job… *facepalm*
Really? I thought they acquiesced to law enforcement’s arm-twisting quite quickly
It’s Ukraine law enforcement they probably did twist their arm till it broke then pulled out the heat gun or sand blaster to make sure they were being honest in their answers.
No arms were twisted. Someone allegedly impersonated a gov employee and stole $10k from a Ukrainian social services agency. A year later the servers were seized by local authorities.
At no point did we ever hand over any customer data, simply because there is nothing to hand over. We have a real time transparency report at the following URL: https://windscribe.com/transparency