{"id":15009,"date":"2014-09-25T16:24:27","date_gmt":"2014-09-25T16:24:27","guid":{"rendered":"http:\/\/kasperskydaily.com\/b2b\/?p=2649"},"modified":"2020-02-26T10:56:03","modified_gmt":"2020-02-26T15:56:03","slug":"when-the-bug-bashes-you","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/when-the-bug-bashes-you\/15009\/","title":{"rendered":"When the Bug Bashes you"},"content":{"rendered":"<p><i>Later\u00a0posts on BashBug\/Shellshock:<\/i><\/p>\n<ul>\n<li><a href=\"https:\/\/business.kaspersky.com\/bashbugshellshock-the-day-after\/2656\" target=\"_blank\" rel=\"noopener nofollow\">Bashbug\/Shellshock: The Day After<\/a><\/li>\n<li><a href=\"https:\/\/www.kaspersky.com\/blog\/shellshock-how-to-check-and-update-potentially-vulnerable-systems\/15011\/\" target=\"_blank\" rel=\"noopener nofollow\">Shellshock: how to check and update potentially vulnerable systems<\/a><\/li>\n<\/ul>\n<p>\u00a0<\/p>\n<p>Infosecurity world is on red alert again due to a new vulnerability discovered in all *Nix systems, including Mac OS X. The situation is arguably as serious as it was with the #Heartbleed discovery earlier this year. \u201cArguably\u201d because while some experts tend to downplay its severity, others claim it is at least as serious as (and probably more dire than) the April \u201chit\u201d of infosec news outlets and blogs. Welcome, #BashBug, aka #Shellshock.<\/p>\n<p style=\"text-align: center\">\n<\/p><p style=\"text-align: left\"><strong>What\u2019s up?<\/strong><\/p>\n<p>A technical description: The vulnerability is present in the Bourne again shell simply known as Bash, \u2013 a Unix shell written in 1989. It is a default shell on Linux and Mac OS X too, which means that all of these systems are affected.<\/p>\n<p>The flaw,\u00a0discovered by Stephane Chazelas of Akamai, <a href=\"https:\/\/threatpost.com\/major-bash-vulnerability-affects-linux-unix-mac-os-x\/108521\" target=\"_blank\" rel=\"noopener nofollow\">allows an attacker to remotely attach a malicious executable to a variable that is executed when Bash is invoked<\/a>.<\/p>\n<p>The US National Vulnerability Database lists the bug as <a href=\"http:\/\/web.nvd.nist.gov\/view\/vuln\/detail?vulnId=CVE-2014-6271\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2014-6271<\/a>, and its overview reads: \u201cGNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.\u201d<\/p>\n<blockquote class=\"twitter-pullquote\"><p>#BashBug: is it #Heartbleed 2.0? #security #redalert<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2Ftp6u&amp;text=%23BashBug%3A+is+it+%23Heartbleed+2.0%3F+%23security+%23redalert\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>The problem is a quarter-century old. And since Bash is currently in \u201cpervasive use\u201d, the bug is almost ubiquitous.<\/p>\n<p>A lot of technical details\u00a0on the bug is <a href=\"https:\/\/securelist.com\/blog\/research\/66673\/bash-cve-2014-6271-vulnerability-qa-2\/\" target=\"_blank\" rel=\"noopener\">available at Securelist now<\/a>.<\/p>\n<p><strong>What they say?<\/strong><\/p>\n<p>There is near consensus that the #bashbug is dead serious. The fact that it\u2019s easy to exploit, potentially extremely harmful, and present in nearly every *Nix system makes it a beast of a vulnerability. NVD lists its Exploitability and Impact subscores at 10.0, while Access Complexity is \u201cLow\u201d.<\/p>\n<p>The <a href=\"https:\/\/access.redhat.com\/articles\/1200223\" target=\"_blank\" rel=\"noopener nofollow\">advisory<\/a> from Red Hat reads: <em>\u201cThis vulnerability <\/em><a href=\"https:\/\/access.redhat.com\/articles\/1200223\" target=\"_blank\" rel=\"noopener nofollow\"><em>CVE-2014-6271<\/em><\/a><em> could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue\u2026 This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this.\u201d<\/em><\/p>\n<p><a href=\"http:\/\/arstechnica.com\/security\/2014\/09\/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it\/\" target=\"_blank\" rel=\"noopener nofollow\">According to Ars Technica<\/a>, <em>\u201cIf Bash has been configured as the default system shell, it can be used by network\u2013based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.\u201d<br>\n<\/em><br>\nSecurity researcher Robert Graham of Errata Security is sure that the #BashBug is as big as Heartbleed, or even more dire.<\/p>\n<p><em>\u201cAn enormous percentage of software interacts with the shell in some fashion,\u201d <\/em>he <a href=\"http:\/\/blog.erratasec.com\/2014\/09\/bash-bug-as-big-as-heartbleed.html\" target=\"_blank\" rel=\"noopener nofollow\">wrote<\/a>. <em>\u201cThus, we\u2019ll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.\u201d<\/em><\/p>\n<p>Graham also points out that the bug is especially dangerous for Internet-of-things devices like video cameras \u201cbecause a lot of their software is built from web-enabled bash scripts. Thus, not only are they less likely to be patched, they are more likely to expose the vulnerability to the outside world.\u201d<\/p>\n<p>Also consider that at least some of these old devices are unpatchable, and things start to look ugly.<\/p>\n<p>On the other hand, Rapid7 isn\u2019t jumping on the \u201cHeartbleed 2.0 bandwagon\u201d, stating that the conditions to exploit it are <a href=\"https:\/\/community.rapid7.com\/community\/infosec\/blog\/2014\/09\/25\/bash-ing-into-your-network-investigating-cve-2014-6271\" target=\"_blank\" rel=\"noopener nofollow\">fairly uncommon for remote exploitation<\/a>:<\/p>\n<p><em>\u201cEvery affected application may be exploitable through a slightly different vector or have different requirements to reach the vulnerable code. This may significantly limit how widespread attacks will be in the wild. Heartbleed was much easier to conclusively test and the impact way more widespread.\u201d<\/em><\/p>\n<p>However, refer to <a href=\"http:\/\/blog.erratasec.com\/2014\/09\/bash-shellshock-bug-is-wormable.html#.VCPRGfl_t8E\" target=\"_blank\" rel=\"noopener nofollow\">this post<\/a> from Robert Graham, who\u00a0says\u00a0that the #Shellshock bug is \u201cwormable\u201d. He has performed some preliminary \u201clight\u201d scans, immediately discovering \u201cabout 3000 systems vulnerable just on port 80, just on the root \u201c\/\u201d URL, without Host field\u201d. Graham says there\u2019s actually much more. And \u2013 red flag! \u2013 someone is already using <strong>masscan to deliver malware<\/strong>. \u201c<em>They\u2019ll likely have compromised most of the system I\u2019ve found by tomorrow morning. If they using different URLs and fix the Host field, they\u2019ll get tons more.\u201d<\/em><\/p>\n<p>Do you hear that ticking clock?<\/p>\n<p style=\"text-align: left\"><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2017\/05\/06020355\/wide3.jpg\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-2651\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2017\/05\/06020355\/wide3.jpg\" alt=\"wide\" width=\"1000\" height=\"667\"><\/a><\/p>\n<p style=\"text-align: left\"><strong>Remote attacks<\/strong><\/p>\n<p>The biggest question: How easily can the bug be exploited in order to perform remote attacks? Conditions for the exploitation are \u201cfairly uncommon\u201d (Red Hat, by the way,\u00a0<a href=\"https:\/\/securityblog.redhat.com\/2014\/09\/24\/bash-specially-crafted-environment-variables-code-injection-attack\/\" target=\"_blank\" rel=\"noopener nofollow\">actually lists them<\/a>). Still, these attacks are quite possible. Wolfgang Kandek, CTO of\u00a0Qualys, offers one such scenario:<\/p>\n<p>\u201c<em>Bash is very often involved in a networked setup to execute commands and that opens up an interesting attack vector. Imagine a webserver that allows you to ping an IP address (my router at home has that function for example), it will most likely just call the \u201cping\u201d executable with the argument that you supplied, probably checking whether the argument is formatted correctly as an IP address. With CVE-2014-6271, if you can control the value of an environmental variable given to the shell, you can make the shell run arbitrary commands. Controlling an environmental variable is not that difficult, as a large number of environmental variables are under control of the attacker, such as the settings for the Referer or the UserAgent. Consequently scenarios where a CGI-BIN setup is used to execute commands on the server can be attacked quite easily.\u201d<\/em><\/p>\n<p><strong>Patches<\/strong><\/p>\n<p>Here\u2019s where things become even more complicated. The fix for <a href=\"https:\/\/access.redhat.com\/articles\/1200223\" target=\"_blank\" rel=\"noopener nofollow\"><em>CVE-2014-6271<\/em><\/a>\u00a0was promptly released by Red Hat, but immediately proved to be incomplete\u00a0[<a href=\"https:\/\/bugzilla.redhat.com\/show_bug.cgi?id=1141597#c23\" target=\"_blank\" rel=\"noopener nofollow\">1<\/a>,\u00a0<a href=\"https:\/\/access.redhat.com\/node\/1200223\" target=\"_blank\" rel=\"noopener nofollow\">2<\/a>]\u00a0and the vulnerability was found to still be exploitable. So a new entry is currently present in NVD \u2013 <a href=\"http:\/\/web.nvd.nist.gov\/view\/vuln\/detail?vulnId=CVE-2014-7169\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/web.nvd.nist.gov\/view\/vuln\/detail?vulnId=CVE-2014-7169<\/a>, with incoming patches for it as well. However, those, which already exist, appear to be pointless, making the current situation look like a \u201ccompound fiasco\u201d.<\/p>\n<blockquote class=\"twitter-pullquote\"><p>Releases of #BashBug patches proved incomplete #security #redalert<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2Ftp6u&amp;text=Releases+of+%23BashBug+patches+proved+incomplete+%23security+%23redalert\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>The new patch is already <a href=\"http:\/\/www.openwall.com\/lists\/oss-security\/2014\/09\/25\/10\" target=\"_blank\" rel=\"noopener nofollow\">offered<\/a> and, most likely due to the severity of the situation, all of the vendors of the affected software will likely release their fixes. Stay tuned and scan the horizon.<\/p>\n<p><strong>Should I panic?<\/strong><\/p>\n<p>It would be impractical to do so.<\/p>\n<p><strong>Okay, then what?<\/strong><\/p>\n<p>First of all, check out <a href=\"http:\/\/shellshock.brandonpotter.com\/\" target=\"_blank\" rel=\"noopener nofollow\">this tool<\/a>\u00a0and use it to check your own servers for the vulnerability. Interestingly, at the time of this article, stats showed that 7362 tests had been run with 749 vulnerabilities found.<\/p>\n<p>It may make sense to still install CVE-2014-6271 patches even though they don\u2019t blast the #BashBug completely: Rapid7 states that the patched packages are more complicated to exploit. So it\u2019s really worth it to check out your package vendor\u2019s sites in\u00a0order to\u00a0obtain\u00a0these updates.<\/p>\n<p>Also Rapid7 says that the unpatchable systems \u2013 such as old\u00a0hardware devices with embedded, or \u201cwelded\u201d software \u2013 should be hidden behind a firewall. And it should be a big and secure one.<\/p>\n<p>For Apple systems users: The necessary updates and technical details are available <a href=\"http:\/\/apple.stackexchange.com\/questions\/146849\/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7\/146851#146851\" target=\"_blank\" rel=\"noopener nofollow\">here<\/a>. OS X 10.9.5 (the latest stable release at the moment) ships with Bash v3.2.51.<\/p>\n<p><strong>Conclusion<\/strong><\/p>\n<p>Apparently there\u2019s a \u201cnew\u201d sheriff in town. The vulnerability was there for many years, thus it\u2019s not impossible that someone knew about it way before the disclosure. It\u2019s not certain whether or not it had been exploited. What damage may it inflict, other than irrevocable loss of nerve cells, is uncertain as well, but if Graham is right\u2026 well, tomorrow may look grim.<\/p>\n<p>So patch up, people, and use whatever is available now.<\/p>\n<p><i>Later\u00a0posts on BashBug\/Shellshock:<\/i><\/p>\n<ul>\n<li><a href=\"https:\/\/business.kaspersky.com\/bashbugshellshock-the-day-after\/2656\" target=\"_blank\" rel=\"noopener nofollow\">Bashbug\/Shellshock: The Day After<\/a><\/li>\n<li><a href=\"https:\/\/www.kaspersky.com\/blog\/shellshock-how-to-check-and-update-potentially-vulnerable-systems\/15011\/\" target=\"_blank\" rel=\"noopener nofollow\">Shellshock: how to check and update potentially vulnerable systems<\/a><\/li>\n<li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>A new nasty bug discovered in Bourne again shell set the infosec on fire, Heartbleed-style. Is it as dangerous as the notorious OpenSSL flaw? It depends&#8230;<\/p>\n","protected":false},"author":209,"featured_media":15933,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3052],"tags":[2194,588,97],"class_list":{"0":"post-15009","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-bash-bug","10":"tag-heartbleed","11":"tag-security-2"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/when-the-bug-bashes-you\/15009\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/when-the-bug-bashes-you\/15009\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/when-the-bug-bashes-you\/15009\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/bash-bug\/","name":"Bash Bug"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15009","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/209"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=15009"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15009\/revisions"}],"predecessor-version":[{"id":33331,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15009\/revisions\/33331"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/15933"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=15009"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=15009"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=15009"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}