Shellshock mitigation with BIG-IP iRules
Yesterday, NIST released information on a new network exploitable vulnerability in the GNU Bash shell as demonstrated by vectors involving parts of OpenSSH sshd, the mod_cgi, and mod_cgid modules in the Apache HTTP Server, scripts executed by DHCP clients, and other situations where setting the environment around a bash process occurs. Vulnerability CVE-2014-6271, or Shellshock as everyone is calling it, allows remote attackers to execute arbitrary code on the target systems. Redhat has a great overview in their security blog posting on the topic. What makes this vulnerability serious is the fact that server-side CGI applications running under the Apache Web Server with mod_cgi or mod_cgid are susceptible. F5's Jeff Costlow is maintaining an article on the Shellshock vulnerability so make sure you check back to that article for F5's official stance. The first step to mitigation is to setup a plan to patch the bash shell on all of your systems. In the interum, if you believe that any of your backend servers are vulnerable (if they are Unix-based then they likely are) and you are fronting them with a BIG-IP, below is an iRule solution you can apply to your Virtual Servers that will protect your servers against attacks. Block-Shellshocked The Block-Shellshock iRule searches for the pattern "*() {*" in the URI and in the HTTP headers. It is rare that this pattern of characters will occur in a URI or HTTP Header so we believe the number of false-positives will be minimal. If the pattern is found, an audit entry will be written to the system log with the client ip as well as the URI, and optionally the HTTP header, that the attack was detected. I chose to issue a reject on the connection. If you want to be more polite to the hackers, you can substitute the "reject" with a 403 - Forbidden. when HTTP_REQUEST { set pattern "*() \{*" ; if { [string match $pattern [HTTP::uri]] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]' in URI '[HTTP::uri]'"; reject; } else { foreach header_name [HTTP::header names] { foreach header_value [HTTP::header values $header_name] { if { [string match $pattern $header_value] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]' in HTTP Header $header_name = '$header_value'; URI = '[HTTP::uri]'"; reject; break; } } } } } Block-Shellshock-full The first iRule gives a more detailed audit if the attack is detected. In the case where that is not a concern and you are more concerned with performance, the HTTP::request method can be used to perform a single search across all of the request header information. This does not cover the POST body, but at this point there is no indication that the exploit is exposed within the body portion of a POST request. This irule reports the client IP along with the requested URI that is the source of the attack. when HTTP_REQUEST { if { [string match "*() \{*" [HTTP::request]] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]'; URI = '[HTTP::uri]'"; reject; } } We will be monitoring this vulnerability over the coming weeks and update the iRule solution if a more optimal one becomes available. Please leave a comment if you have any suggestions. And, make sure you monitor Jeff's article for updates. Special Considerations Please be aware that this iRule will reject any connections containing the string "() {" in the URI or header. While we are confident that this is not a valid pattern for standard headers, there could be situations where custom application values contain this string pattern and this iRule would cause issues to those applications. We suggest running the longer iRule and actively monitoring the system log for false positives. If you find a case where your custom application is being blocked, you can customize the first iRule to exclude the header your application relies on.
CVE-2014-6271 Shellshocked
It's a good thing we are naming all of our vulnerabilities now; it's easier to keep track of them. I haven't seen an official designation for CVE-2014-6271, but Shellshock seems appropriate. This new vulnerability may allow a remote attacker to execute instructions on your computer using a feature of the bash shell. A shell is a command line user interface with complicated features akin to programming languages. One feature of bash is to take user input from its environment. Unfortunately this environment can contain executable commands and in some cases can be manipulated by a remote user. F5 has confirmed that BIG-IP's web GUI is vulnerable to an authenticated user. We currently know of no unauthenticated exploits, either against the management interface or against the traffic interfaces. We can enumerate through RedHat's security blog's list -- not a comprehensive list -- to look at some ways a BIG-IP could be exploited. • BIG-IP does not use ForceCommand in sshd_config, so users cannot bypass ForceCommand. • BIG-IP does not contain any bash CGI programs, although it is possible that some CGI programs spawn subshells. • BIG-IP does contain mod_php, but the scripts are not vulnerable. • BIG-IP does contain DHCP dhclient and is in theory vulnerable to a malicious DHCP server. This is the only known unauthenticated remotely exploitable vector at this time and is only vulnerable on the management interface. You may disable DHCP on the System::Platform page. • BIG-IP limits the use of bash to authenticated Administrator level accounts. Non-Administrators only have access to tmsh and do not have access to bash. We still do not believe the traffic passing interfaces of a BIG-IP can be exploited. Please protect your management interface and ensure that it is not exposed to the internet. F5 will be patching CVE-2014-6271 on all BIG-IP releases. Sol15629 has been published. Update: BIG-IP iRule mitigation has been posted. F5 LineRate has posted their mitigation. ASM has signature updates.
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.3 Ways to use BIG-IP ASM to Mitigate Shellshock
UPDATE (9/28/2014): Our security team indicates that we're now seeing the majority of attempted exploits of Shellshock coming in through input paramters. They've provided ASM signatures to mitigate and recommend customers use these signatures to protect their applications. You can find these signatures and more information in this post:https://devcentral.f5.com/s/articles/bash-shellshock-mitigation-using-asm-signatures I had a great conversation this morning with Tom Spector, Enterprise Network Engineering Lead for Security here at F5, about the ways in which customers can use BIG-IP Application Security Manager (ASM) to mitigate Shellshock. As you're no doubt aware, the potential exploits of Shellshock continue to evolve and we're seeing both HTTP header and input fields used as a transport mechanism for this Bash vulnerability. Web application firewalls (WAF) are a well known tool for protecting applications both on inbound (request) and the outbound (response) across headers and payloads. In the case of Shellshock, BIG-IP ASM is able to provide protection regardless of whether the HTTP method is POST or GET. Tom offered the following suggestions when using ASM to mitigate Shellshock. Character Restrictions Restrict the character ‘{‘ in HTTP headers. Unlike parentheses that are commonly used in headers the character ‘{‘ is not as commonly used (although there may be cases when it is). To do this in BIG-IP ASM: Ensure that under the blocking settings (Security -> Application Security -> Blocking -> Settings) you have checked for learn/alarm/block the violation for ‘Illegal meta character in header’ (found under ‘Input Violations’ section) Disallow the characters ‘{‘ in the header character set configuration (Security -> Application Security -> Headers -> Character Set) Save and apply the policy You can also restrict the characters ‘(‘, ‘)’, and ‘{‘ in parameter values. These characters are not typically found in parameter values (some restrictions apply such as phone numbers that include parentheses in the values). To do this in BIG-IP ASM: Ensure that under the blocking settings (Security -> Application Security -> Blocking -> Settings) you have checked for learn/alarm/block the violation for ‘Illegal meta character in value’ (found under ‘Input Violations’ section) By default, ASM already disallows the characters ‘(‘, ‘)’, and ‘{‘ in parameter values. You can verify this by looking at the parameter value character set configuration (Security -> Application Security -> Parameters -> Character Set -> Parameter Value) Save and apply the policy Signatures Ensure all signatures relevant to your environment are enabled (and are not in staging as is any parameter you wish to protect). A few signatures are aimed at identifying shell command injections included in headers or parameters. While this does not target the Shellshock initial attack vector (using the “() {“ sequence) it does handle the injection portion of the attack, i.e. bash commands included after the sequence such as netcat and telnet. Additionally, consider adding these ASM signature to your arsenal: https://devcentral.f5.com/s/articles/bash-shellshock-mitigation-using-asm-signaturesper our security team's recommendation. Cookies One of the headers that may be targeted is Cookie. Using cookie encryption and/or ASM cookie enforcement will restrict any cookie tampering and catch those attempts to manipulate the cookie header of an application. Please ensure you carefully evaluate the potential impact these changes can have in terms of false positives. In some cases the characters ‘(‘, ‘)’, and ‘{‘ are used in a legitimate manner within an application and blocking them my cause valid traffic to be denied. As patches for vulnerable systems are available, make plans to roll them out as soon as possible. We will continue to update mitigations and provide additional guidance on mitigating Shellshock as they become available. You can always find the latest information regarding Shellshock on f5.com/shellshock. Stay safe.
Shellshock mitigation with LineRate Proxy
News hit yesterday of a critical vulnerability, CVE-2014-6271, that is now being called 'shellshock'. The flaw affects GNU bash and has pretty serious implications, especially if you're running any server-side CGI applications. There is a very nice, well-rounded write-up at troyhunt.com - Everything you need to know about the Shellshock Bash bug. My colleague, Jeff Costlow, has also written about shellshock and it's BIG-IP implications. The LineRate development team is hard at work trying to determine whether LineRate itself is susceptible (we believe it's not so far... UPDATE: LineRate is not vulnerable! See SOL15629 for more detail.); in the meantime I thought I could demonstrate the power of LineRate proxy by quickly writing a mitigation script that rejects HTTP requests that contain the exploit. You should use this script on your LineRate proxy if you are concerned that any of your backend ("real") servers are vulnerable. You'll note that the script checks both the headers and the URL query string for a suspicious string, () { . Initial information suggests that query string parameters can be used for the exploit, but I haven't seen any evidence of this yet. The HTTP specification and URL encoding and decoding will make this vector more difficult than using a HTTP header. Here's the script: "use strict"; var vsm = require('lrs/virtualServerModule'); var querystring = require('querystring'); var bad_pattern = /\(\)\s*\{/; vsm.on('exist', 'vs_http', function (vs) { console.log('Exploit mitigation script installed on Virtual Server: ' + vs.id); vs.on('request', function (servReq, servResp, cliReq) { // check headers for (var i in servReq.headers) { if (bad_pattern.test(servReq.headers[i])) { console.log("Suspicious pattern found in header; returning 403."); servResp.writeHead(403); servResp.end('Forbidden'); return; } } // check querystring var qs = querystring.parse(servReq.url); for (var key in Object.keys(qs)) { if (bad_pattern.test(qs[key])) { console.log("Suspicious pattern found in header; returning 403."); servResp.writeHead(403); servResp.end('Forbidden'); return; } } // if we're still here, request is ok cliReq(); }); }); Please leave a comment or reach out to us with any questions or suggestions and if you're not a LineRate user yet, remember you can try it out for free.DevCentral Top 5: Oct 6, 2014
These past two weeks have proven to be more than eventful with the "shock"ing discovery of a critical bash vulnerability that stole the security headlines for several days. Times like these might have you repeating the words of the infamous Ben Jabituya, "I don't know about you, but I am planning to scream and run." Fortunately for all of us, there's no need to scream and run...there's only a need to sit back and read about the most awesome articles that anyone, anywhere has to offer. Check out this edition of the DevCentral Top 5!! CVE-2014-6271 Shellshocked As I stated in the opening paragraph, all our collective worlds got rocked when the Shellshock vulnerability was announced. This vulnerability allows a remote attacker to execute instructions on your computer using a feature of the bash shell. Enter Jeff Costlow; one of the most intelligent guys you'll ever meet when it comes to security. Literally the same day Shellshock was released, Jeff wrote this article to explain all the details of the vulnerability and also outlined ways your BIG-IP could be exploited. In addition, he gave some great advice on how to mitigate the vulnerability using several options available from F5...iRules, LineRate, ASM (with custom signatures), and best practices (like, don't expose your management interface to the Internet). Jeff also participated in a Shellshock guru panel where several F5 security experts talked about the vulnerability, how it works, why it's bad, and how to mitigate it using F5 technology. Sorry, Johnny Five. Yes Disassemble! Jason Rahm takes us back to yesteryear with a metaphor from one of our favorite movies from the 1980s. In that movie, Johnny 5 has a big fear of being disassembled (and rightfully so, I guess). Well, Jason keeps Johnny 5 safe from disassembly, but doesn't afford that same luxury for Tcl code. As you all know, Tcl forms the foundation of several code environments on the BIG-IP (iRules, iCall, iApp, tmsh). Many of us want to know what the Tcl interpreter is actually doing from an instruction standpoint, and Jason shows us that the way to analyze the bytecode is to disassemble it. The command that will show how the interpreter works its magic is tcl::unsupported::disassemble. In one of the most technically-hardcore articles ever written on DevCentral, Jason digs deep into two different solution sets and reminds us that it's always a good idea to fine-tune your code. Less is more. Less objects. Less stack depth. Less instantiation. Reviewing bytecode is good for that, and it's possible with the native Tcl code. APM Security: Protecting Internal Resources Using ACLs Bart Sikkes wrote up a great security solution for the APM in Portal Access mode. The APM in Portal Access mode gives instant access to internal resources for authorized users, but it might also give access to other users if you aren't careful. Bart sets up a test environment using three internal resources: OWA, intranet website, and source code programming website. Two of these should be accessible through the APM but the third should not. Bart walks through some great examples of how someone might find a work around to access the protected internal resource. He also provides a great solution using APM ACLs that will ensure users only access the intended resources. Introducing LineRate Lightning series (and Snippet #1 - HTTP referer blocking) Everyone loves the iRules 20 Lines or Less series, right? LineRate is no exception. The only thing is that the LineRate proxy uses a Node.js scripting engine embedded into the HTTP data path, so it can't directly use iRule scripts. So, the LineRate guys created a new series on DevCentral called "LineRate Lightning" and these articles will contain snippets of code that aim to be quick, powerful, and even a little bit flashy. The inaugural LineRate Lightning post includes a simple snippet of code that does HTTP referrer blocking based on a whitelist of permitted referrers. Simply add the referring domains that you'd like to permit in the domain_whitelist list and change vs_http to match the name of your virtual server. Pretty cool and simple solution, huh?!? Check back often and regularly to read this series that so beautifully complements the iRule 20 LoL! Shellshock mitigation with BIG-IP iRules Some call him the inventor of iControl, some call him the creator of the iRule editor, some call him the most interesting man in the world, I simply call him "Joe the Show." Joe Pruitt fired up two separate iRule solutions to mitigate the Shellshock vulnerability the day after it was released by NIST. This is just another example of the power and flexibility of F5 technology. Who else in the world provides so many options to secure critical infrastructure in such a short amount of time? Joe wrote and tested these Shellshock-mitigating iRules and then posted them on DevCentral for all the world to use. He reminds us that we should set up a plan to ultimately patch the bash shell on all our systems. While you are creating and implementing the patch plan, you can use the iRule solution to protect your servers against attacks.Vulnérabilité Shellshock - CVE-2014-6271 et CVE-2014-7169
Shellshock est une vulnérabilité sérieuse pouvant engendrer des dégâts importants. Nous pouvons la comparer à Heartbleed mais avec un niveau de dangerosité plus important. Les client F5 peuvent vérifier icila vulnérabilité de leurs équipements F5. F5 a confirmé que l’interface graphique des BIGIP était vulnérable pour les utilisateurs authentifiés, à condition que l'interface de management soit exposée sur internet. Les équipes de développement ainsi que nos Solution Architect Security travaillent depuis l’annonce pour développer un correctif sur nos boitiers. Il est donc important que l’interface de management de vos BIGIP ne soit pas routée sur Internet. A l’heure actuelle, nous ne connaissons aucun exploit exécuté de façon non authentifiée, que cela soit sur l’interface de management ou sur les interfaces gérants le trafic. Vous comprenez donc que les équipements les plus vulnérables dans votre infrastructures sont vos serveurs WEB, et F5 va vous permettre de les protéger en attendant le correctif de ceux-ci.En attendant la sortie d’un hotfix pour TMOS et si vous devez exposer l’interface de management de vos BIGIP à Internet, assurez-vous d’en sécuriser l’accès (gestion des utilisateurs et mots de passes, restriction des accès par l’IP source, etc). Voir le lien : http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13092.html Shellshock utilise les headers HTTP ainsi que leurs caractéristiques pour donner un accès non autorisé au shell de l’OS, le Bash. L’attaque Shellshock utilise une faille dans Bash pour permettre aux pirates d’exécuter des commandes à distance qui normalement auraient dû être bloquées. L’exécution de ces commandes est donc très critique. Comment cela fonctionne : Cette vulnérabilité affecte le GNU Bash, et si vous utilisez des application CGI sur vos serveurs, cela devient critique. Il peut, une fois piraté, permettre l’exécution de commandes dans votre système. Concrètement, le pirate joue l’attaque suivante - () {- dans un header HTTP (cookie, referer, paramètre …) suivi d’une commande Bash (ping, ls, wget …). Quand ces headers sont transférés dans le script CGI, ils sont stockés en tant que variable d’environnement, et c’est ici que l’attaque commence. Finalement, Bash exécute les commandes grâce à cette attaque. Je vous laisse imaginer tout ce qu’un pirate pourrait exécuter !!!!! Comment se protéger : A l’heure où j’écris ces lignes (quelques heures après l’annonce – et non la découverte , je vous laisse lire l’histoire de cette attaque) plusieurs solutions d’atténuations et de blocagessont envisageables. Je vais donc vous rediriger vers les différents articles ASKF5 et DevCentral traitant de cette attaque. Une fois la solution officiel annoncée, je mettrai à jour cet article. Avant tout, il est important de noter que les clients qui utilisent ASM étaient en partie protégés avant l’annonce de la vulnérabilité. Toutes les tentatives d’exploiter cette vulnérabilité via les paramètres sont bloquées en utilisant des signatures existantes par défaut dans ASM. De même, les tentatives d’exploitation via les entêtes de Cookies déclencheront une violation de type "Cookie not RFC-compliant". Assurez-vous tout de même que les signatures sont actives et pas en « staging ». Pour les tentatives d’exploitations via les URL ou les valeurs de paramètres et objets XML, une signature ASM spécifique est disponible :https://devcentral.f5.com/s/articles/bash-shellshock-mitigation-using-asm-signatures. F5 vient de mettre à jour (lundi 29 Septembre 2014) sa base de signature ASM avec l'ajout de cette nouvelle. Pour les clients qui n’ont pas (encore) implémenté ASM (le Pare-feu Applicatif Web de F5) il est possible de protéger vos services WEB en mettant en place un iRule sur Big-IP :https://devcentral.f5.com/s/articles/shellshock-mitigation-with-big-ip-irules Cette protection par iRule est rapide à mettre en place et permet de bloquer les attaques Shellshock contenues dans les URI et les entêtes http. En revanche, pour bloquer les autres méthodes d’attaque, comme les cookies ou les payloads encodées, seule ASM (le Web Application Firewall de F5) apportera une protection complète. Voici les liens traitant de la vulnérabilité : Lien officiel décrivant la vulnérabilité : https://f5.com/solutions/mitigation/mitigating-the-bash-shellshock-cve-2014-6271-and-cve-2014-7169-vulnerabilities La SOL sur ASKF5 : http://support.f5.com/kb/en-us/solutions/public/15000/600/sol15629.html Article de Lori présentant comment se protéger et comment bien configurer son ASM : https://devcentral.f5.com/s/articles/3-ways-to-use-big-ip-asm-to-mitigate-shellshock Signature ASM : https://devcentral.f5.com/s/articles/bash-shellshock-mitigation-using-asm-signatures Base de signature ASM mise à jour le 29 Septembre :ASM-SignatureFile_20140928_071720 iRule beta : https://devcentral.f5.com/s/articles/shellshock-mitigation-with-big-ip-irulesShellshock: Keep Calm and Mitigate
#shellshock #nodejs #DevOps Yes, it is that bad. But don't panic. Shellshock, appropriately and of course punnily named, is ravaging the Internet right now. Active exploits continue to grow in number and in complexity. While there are multiple avenues through which this vulnerability can be exploited, the most active one at the moment appears to be via vulnerable Internet-facing systems running web applications. These attacks take advantage of the lax constraints on HTTP headers that allow strings of nearly limitless length to be passed not just to the web server, but on to the system via CGI. Once passed, a 22 year old GNU Bash vulnerability allows the code embedded in the HTTP header to be executed. That code can be just about anything. A quick GIS will net you hundreds of sites documenting actual attempts at exploits including complete shell scripts designed to download and execute other malicious content. While the exploit mechanism is fairly simple, the results are not. If it's a command you can run in Bash, you can probably trick the system into executing it. "rm -rf" isn't beyond imagining. Neither is "shutdown -h now." It really depends on what the attacker wants to accomplish, and that could be anything. As Barrett Lyon said in his blog yesterday, "expect the Internet to be a little messy for the next few months." The good news is that for at least web-borne attempts to mitigate attacks there are a variety of options already available. System patches will of course be flying fast and furious, but we (and that includes the bad guys) all know it takes time to obtain, certify and deploy those patches. In the meantime it's imperative to put a stop to the attacks and that means you need something fast. Like, right now. This is the kind of situation for which programmability is exceedingly well suited. While the attack varies depending on what the attacker is trying to do, the exploit depends on the consistent presence of four characters at the beginning of an HTTP header: () {. Scripting solutions - whether iRules or node.js with LineRate - can detect this pattern in any HTTP header and then be dealt with accordingly (while you may feel like crafting a cocky HTTP response to the request and you certainly can when you've got a programmable data path, it's never a good idea to poke a badger, m'kay? I suggest just rejecting the connection, but that's me). Web Application Firewalls (WAF) are also going to be a boon in mitigating this attack vector through web applications. The requirement for the string composition to begin consistently means it's a good candidate for a signature. WAFs like BIG-IP ASM that support custom signatures can be used immediately to block these attacks. Bonus: WAFs are already adept at recognizing attempts to evade detection such as encoding and escaping of characters, both of which will likely be used more and more frequently as organizations begin to block exploit attempts. No matter how you decide to mitigate this one, MITIGATE IT NOW. Yes, caps were necessary, especially given the news this summer that two months after public disclosure there were still 300,000 servers vulnerable to Heartbleed. Heartbleed was bad, but Shellshock is badderest. Heartbleed was rated a CVSS v2 severity score of 5 and an impact of 2.9. Shellshock? A 10 on both counts. And I suspect that's only because the scale doesn't go to 11. Maybe it should. F5 customers can track the status of F5 with respect to Shellshock as well as access both BIG-IP and LineRate mitigating solutions here. Keep calm and mitigate.
