So last week the big news was about the cross platform exploit in BASH that we covered in our article – Everything You NEED To Know About Shellshock Bug In BASH.
As mentioned in the comments, a certain combination of circumstances and configuration options can leave OpenVPN vulnerable to Shellshock.
This could be a pretty serious issue as I’m sure there are thousands of OpenVPN servers sitting around fairly idle, that are unlikely to be updated and around about to get pwned. If the OpenVPN is using system level pre-auth with the auth-user-pass-verify option – they will be in trouble.
The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg. Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says.
Shellshock affected the crucial and ubiquitous *nix component Bash up to and including version 4.3. Mullvad chief technology officer Stromberg described the flaw in a forum post overnight, adding that he disclosed the vulnerability to OpenVPN sometime last week.
“OpenVPN servers are vulnerable to Shellshock under certain configurations,” Stromberg said. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client.
“One option used for username+password authentication is auth-user-pass-verify. If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username. This attack vector is pre-auth.”
There’s a whole list of Shellshock PoCs here on Github including the one for OpenVPN – Shellshocker PoCs. The exploit walkthrough is available here, including the OpenVPN config and log output – OpenVPN ShellShock PoC.
I’m honestly not sure how much impact this will actually have in the wild as to know that we’d have to know how common it is for OpenVPN systems to auth in this manner.
A proof of concept for the exploit has surfaced online. Those using OpenVPN can dodge Shellshock by preventing Bash from running scripts. OpenVPN’s Gert Doering told Threat Post OpenVPN was vulnerable only on systems where /bin/sh points to /bin/bash, or when scripts running bash as an interpreter were called explicitly.
“What you want to do from OpenVPN’s point of view is to ensure that you’re not using a 2.2.x version anymore, and that you just do not run your scripts using bash (#!/bin/bash) but use a shell that is better suited to script usage, like ash/dash,” Doering told the publication. “Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert.”
Vendors have released solid and borked patches for the Shellshock bug over the last week since the flaw was revealed. The patching prompted Blighty’s privacy watchdog to urge organisations patch their Bash instances
Apple has issued a patch for the smaller subset of affected users, while F5 has moved to stop holes in its line of BIG-IP products including the ARX, Enterprise Manager and BIG-IQ systems, but not FirePass or LineRate proxy systems. Stromberg in April identified the susceptibility of OpenVPN to the HeartBleed vulnerability.
The OpenVPN systems will only be vulnerable if /bin/sh points to /bin/bash and if they don’t use an alternative (more suitable) shell like ash/dash (which is the default shell in Debian systems).
There are also other vectors being exposed like QNAP NAS devices (which was one of my worries), anything Linux based with BASH that is unlikely to get updated is at fairly high risk:
Shellshock Attacks Hit Major NAS Kit; IoT Next?
Shellshock – the bug that just keeps on giving.
Source: The Register
Dave Cox says
Hi,
I am the author of the comment left a couple weeks ago referred to in this post. The method of authentication required to exploit shellshock is actually a very common method of authentication. Most OpenVPN deployments either use RADIUS (not at risk) or via a bash script. If they use a bash script its usually via a client-connect script (auth-user-pass-verify via-env is at risk as well but rarely used) client-connect does not require authentication.