Shellshock – The SIP Proxy Edition
The recent Shellshock and Heartbleed vulnerabilities have something in common – they both affect very infrastructural services. That is the reason their magnitude is much bigger than any other ol’ vulnerability out there. “Everyone” uses bash, “everyone” uses OpenSSL. Shock the shell However, one of the differences is that bash isn’t a public facing service like OpenSSL. Bash is simply the shell service of the underlying operating system. To be able to get to bash and exploit the vulnerability – one has to find a way to remotely “talk” with and feed it their evil commands via environment variables. Arguably, the most common path to reach bash is through a web server that makes use of the CGI technology. By default, CGI creates user-controlled environment variables, which are then parsed by bash, for every HTTP request the server accepts. This means that exploiting bash on such a system is as easy as sending an HTTP request to a CGI controlled page. However, CGI isn’t the only service that uses bash “behind the scenes”. DHCP services are affected, SSH and Telnet are affected, FTP services are affected. Some SIP proxies are also affected, we will learn why and how to mitigate them. SIP Express Router and friends Popular open source SIP proxies, such as Kamailio, have been found vulnerable to Shellshock. The author of a POC tool called sipshock has written a very clear explanation on the matter: The exec module in Kamailio, Opensips and probably every other SER fork passes the received SIP headers as environment variables to the invoking shell. This makes these SIP proxies vulnerable to CVE-2014-6271 (Bash Shellshock). If a proxy is using any of the exec functions and has the 'setvars' parameter set to the default value '1' then by sending SIP messages containing a specially crafted header we can run arbitrary code on the proxy machine. This means that if you have a public facing SIP proxy running a SIP Express Router implementation, you should patch your bash immediately. If you have an F5 LTM doing load balancing for that SIP server – a simple iRule will save you the headache of patching the operating system, and give you breathing room to do so properly. Mitigate Shellshock SIP with BIG-IP iRules The following iRule will detect SIP requests which contain the Shellshock pattern in one of the headers: when CLIENT_DATA { set sCVEPattern "*: () \{*" set bCVEFound 0 if { [string match $sCVEPattern [UDP::payload]] } { set bCVEFound 1 } } when SIP_REQUEST { if { $bCVEFound } { log local0. "Detected CVE-2014-6271 Shellshock attack! IP: '[IP::client_addr]' From: [SIP::from] To: [SIP::to]" reject } } Create a new iRule and attach it to your SIP proxy virtual server. Make sure the Virtual Server has “UDP” set as protocol, and is assigned with a SIP profile.Bash Shellshock Mitigation Using ASM Signatures
Update: The signature mentioned in this article have been released as part of an Attack Signature Update. You may head to https://downloads.f5.com to download the file manually, or use the automatic update feature in ASM. This week we've seen new vulnerabilities with massive damage potential come to light – CVE-2014-6271,CVE-2014-6277 and CVE-2014-7169 - named quite appropriately "Shellshock". Background You can find details regarding this bash vulnerability on the Red Hat security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ In a typical exploit, the payload is sent through a header (typically Cookie, Referrer or User-Agent) and takes advantage of the way the web server saves the data in that request to environment variables. A malicious request will attempt to fool the bash parser by sending a payload that will invoke a system command, for instance: GET /home.php HTTP/1.1 Host: example.com User-Agent: () { :;}; /bin/bash -c "ls" The string "() { :;};" means it is a function declaration. The string is followed by various shell commands – in our case it is execution of the "ls" command. Mitigation using F5 ASM Attack Signatures The following signature will catch attempts to exploit this CVE: headercontent:"() {"; This signature is compatible with all BIG-IP versions. To prevent any other potential exploitation attempts via the URL or a parameter, two additional signatures can be used: uricontent:"() {"; objonly; valuecontent:"() {"; norm; Note: The signatures have been updated to catch exploit attempts in all their variations. It is important to note, that all attempts to exploit this vulnerability via HTTP parameters and several known exploits via the HTTP header are already mitigated using existing "command execution" and "predictable resource location" signatures. Exploits via the Cookie header will encounter the "Cookie not RFC-compliant" violation. You need to make sure they are enabled and are not in staging. To protect your application, create those user-defined signatures and associate them with the relevant security policy. Make sure that the signatures are not in staging.
Mitigating the Unknown
Mitigating “0-day” attacks, which are named like that because the programmer has zero days to fix the flaw, is apparently impossible. However in practice they can be significantly mitigated. We can buy some time by heavily reducing the “vulnerability window” (until the vulnerability is patched or a specific signature is deployed), thus shifting those attacks to be “N-day” attacks. Once a widely used service has a “0-day” publicly disclosed, massive internet scans for vulnerable servers (known also as “campaigns”) are launched almost immediately. Those scans rely on bots either scanning the whole IP range or searching for potential targets using search engines (known as “Google Dorks”). Being a “0-day” attack, there is no complete protection against it. However a good assumption will be that there will pass a certain time until the exploit will evolve enough to include variations and to deploy evasions or to be customized for a specific target. That’s where a good level of a proactive protection required. A typical “0-day” timeline might look like that: A proactive mitigation strategy includes the following ingredients: positive security, proactive negative security, and attack symptoms mitigation. Taking the WAF as an example, positive security might consist of whitelisting only the needed meta-characters (while blocking all other), enforcing HTTP compliance, configuring mandatory request headers, and narrowing down HTTP methods, and file types. And much more can be whitelisted. Whitelisting the entire application (building full positive security model) can be challenging sometimes. It is not less important to rely on proactive attack signatures which are not coupled with a specific CVE, but rather focusing on generic exploitation and evasion patterns and those which try to catch the actual post exploitation payload, regardless of the specific weakness which allowed delivering it in first place. Due to the automation of the “campaign” process, a crucial mitigation factor during the “vulnerability window” might be also relying on detecting automation attack symptoms, such as deploying strong bot detection techniques, blocking TOR exit nodes and having a good IP reputation feed. ShellShock Example I want to use the latest high profile “ShellShock” vulnerability (CVE-2014-6271 and friends), and see how we take this theory into practice. Let’s take some of the popular real attack vectors used in this recent attack and see how specifically BIG-IP ASM detected them using the proactive approach, before there was a designated “ShellShock” signature. The attack vectors are a mix taken from Exploit-DB, Metaslploit, shellshock.py, detectify.com portal, and requests recorded by honeypots. Result of running the vectors against ASM As we can see all of those vectors were blocked. Blocked requests in the ASM event log Let’s dig in and understand what prevented the exploitation. We can see that the exploit is sent via the “User-Agent” header. It is running “/bin/bash” to download the malware using “wget”, running it using Perl and finally removing the malware file itself. Exploit in the wild Signature triggered by an exploit in the wild Without being aware to the actual weakness “() { :;};” which triggers the code execution, the exploit is caught for several reasons. First, we see that it is targeting the “/cgi-bin/bash” location, thus triggering 2 URI signatures looking for this senstive URL (200000034 and 200100316). Second, ASM caught the actual command that performs the server takeover (the “payload”) by a signature that looks for calling executables from “/bin” directory (200003058). This is the exact example of proactive signatures which look for the actual “takeover” payload or the senstive location/resources that are being targeted, rather than only focusing on the exact weakness that opens the door for exploitation. As for postive security, customers who would fence themselves with non legitimate or very rare characters in headers such as “[“, ”]”, ”`”, ”{“, ”}” would have even prevented the 0-day attack itself ( “{“ character in the case of ShellShock ). Several other signatures (2000021069 and 200021092) for automated user-agents, “wget” and “perl”, are also triggered as the payload is delivered throught the user-agent header (which is true for most of the "ShellShock" exploits). Let’s observe another attack vector: shellshock.py exploit Signature triggered by shellshock.py We see the same “/bin” execution signature (200003058), however we also detect a symptom of a suspicious behavior and a signature for automated python client is fired (200021101). While looking on the exploit published on “Exploit-DB” and some other vectors in the wild we see that the only signature that bravely shields against their successful exploitation is the same “/bin” execution signature (200003058). Of course, if there was another command that does not have a corresponding signature (because it is not considered sensitive, most likely causes false positive or just missing) the attack vector could penetrate (like in the case of “() { :; }; ping x.x.x.x” vector). But that’s where our previously mentioned assumption takes place. There is a crucial time, during the “vulnerability window”, just before the exploit expands to several variations or being evolved to other payloads as well. It is not by accident that we can rely on that single signature to buy us some time before the patch is applied. Exploit from Exploit-DB Signature triggered by exploit from “Exploit-DB” Another proactive measure which is directly related to attack symptoms and can serve as a life belt during the “vulnerability period” is using ASM’s bot protection features which incorporates several state-of the art techniques to identify automated bots regardless of the payload they are trying to deliver. Afterword We are not stating that there is a complete protection against previously unknown attacks, however, there is definitely an already existing proactive set of tools that might significantly lower your chances for compromise in a critical exposed period until the full patch is deployed.