OpenVPN Vulnerable To Shellshock Exploit

The New Acunetix V12 Engine


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.

OpenVPN Vulnerable To Shellshock Exploit

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

Posted in: Exploits/Vulnerabilities, Linux Hacking


Latest Posts:


Malcom - Malware Communication Analyzer Malcom – Malware Communication Analyzer
Malcom is a Malware Communication Analyzer designed to analyze a system's network communication using graphical representations of network traffic.
WepAttack - WLAN 802.11 WEP Key Hacking Tool WepAttack – WLAN 802.11 WEP Key Hacking Tool
WepAttack is a WLAN open source Linux WEP key hacking tool for breaking 802.11 WEP keys using a wordlist based dictionary attack.
Eraser - Windows Secure Erase Hard Drive Wiper Eraser – Windows Secure Erase Hard Drive Wiper
Eraser is a hard drive wiper for Windows which allows you to run a secure erase and completely remove sensitive data from your hard drive by overwriting it several times with carefully selected patterns.
Insecure software versions are a problem Web Security Stats Show XSS & Outdated Software Are Major Problems
Netsparker just published some anonymized Web Security Stats about the security vulnerabilities their online solution identified on their users’ web applications and web services during the last 3 years.
CTFR - Abuse Certificate Transparency Logs For HTTPS Subdomains CTFR – Abuse Certificate Transparency Logs For HTTPS Subdomains
CTFR is a Python-based tool to Abuse Certificate Transparency Logs to get subdomains from a HTTPS website in a few seconds.
testssl.sh - Test SSL Security Including Ciphers, Protocols & Detect Flaws testssl.sh – Test SSL Security Including Ciphers, Protocols & Detect Flaws
testssl.sh is a free command line tool to test SSL security, it checks a server's service on any port for the support of TLS/SSL ciphers, protocols as well as recent cryptographic flaws and more.


One Response to OpenVPN Vulnerable To Shellshock Exploit

  1. Dave Cox October 7, 2014 at 12:57 pm #

    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.