Feedback Friday: ‘Shellshock’ Vulnerability – Industry Reactions
Posted on September 28, 2014 by Kara Dunlap in Security
The existence of a highly critical vulnerability affecting the GNU Bourne Again Shell (Bash) has been brought to light this week. The security flaw is considered by some members of the industry as being worse than the notorious Heartbleed bug.
GNU Bash is a command-line shell used in many Linux, Unix and Mac OS X operating systems. The vulnerability (CVE-2014-6271) has been dubbed “Bash Bug” or “Shellshock” and it affects not only Web servers, but also Internet-of-Things (IoT) devices such as DVRs, printers, automotive entertainment systems, routers and even manufacturing systems.
By exploiting the security hole, an attacker can execute arbitrary commands and take over targeted machine. Symantec believes that the most likely route of attack is through Web servers that use CGI (Common Gateway Interface). There have already been reports of limited, targeted attacks exploiting the vulnerability.
A patch has been made available, but it’s incomplete. Until a permanent fix is rolled out, several organizations have launched Shellshock detection tools. Errata Security has started scanning the Web to find out how many systems are affected, and Symantec has published a video to demonstrate how the flaw can be exploited.
The security community warns that the vulnerability can have serious effects, and points out that it could take a long time until all systems are patched.
And the Feedback Begins…
Ian Pratt, Co-founder and EVP at Bromium:
“The ‘shellshock’ bash vulnerability is a big deal. It’s going to impact large numbers of internet-facing Linux/Unix/OS X systems as bash has been around for many years and is frequently used as the ‘glue’ to connect software components used in building applications. Vulnerable network-facing applications can easily be remotely exploited to allow an attacker to gain access to the system, executing with the same privilege the application has. From there, an attacker would attempt to find a privilege escalation vulnerability to enable them to achieve total compromise.
Bash is a very complex and feature-rich piece of software that is intended for interactive use by power users. It does way more than is typically required for the additional role for which it is often employed in gluing components together in applications. Thus it presents an unnecessarily broad attack surface — this likely won’t be the last vulnerability found in bash. Application developers should try to avoid invoking shells unless absolutely necessary, or use minimalist shells where required.”
Mark Parker, Senior Product Manager at iSheriff:
“This bash vulnerability is going to prove to be a much bigger headache than Heartbleed was. In addition to the general Mac OS X, Linux and Unix systems that need to be patched, there are also thousands upon thousands of Internet connected Linux and Unix based embedded devices, such as DVRs, home automation systems, automotive entertainment systems, mobile phones, home routers, manufacturing systems and printers.
Most of these devices will be susceptible because most Linux based devices run bash, it is such an integral part of the Linux OS. I anticipate that we will be continue to see the fallout from this vulnerability for a long time to come.”
Carl Wright, General Manager of TrapX Security:
“We feel that industry will take this very seriously and come out with patches for this vulnerability ASAP. It could take us years to understand how many systems were compromised and how many were used to escalate privileges into systems without this vulnerability. The transitive trust nature of directory architectures and authentications systems could mean we are living with this far beyond patching the current systems if this exploit has been taken advantage of even at a small 1% level.”
Coby Sella, CEO of Discretix:
“This is the second time over the last six months when a key infrastructure component used by billions of connected things across a variety of industries has been compromised. We see this problem only getting worse as more and more unsecured or not adequately secured things are rolled out without any comprehensive security solution that reaches all the way down to the chipset. Real solutions to this problem must cover every layer from the chipset to the cloud enabling companies to remotely insert secrets into the chipset layer via secured connections within their private or cloud infrastructure.”
Nat Kausik, CEO, Bitglass:
“Enterprises with ‘trusted endpoint’ security models for laptops and mobile devices are particularly vulnerable to this flaw. Malware can exploit this vulnerability on unix-based laptops such as Mac and Chromebook when the user is away from the office, and then spread inside the corporate network once the user returns to the office.”
Steve Durbin, Managing Director of the Information Security Forum:
“The Bash vulnerability simply stresses the point that there is no such thing as 100% security and that we all need to take a very circumspect and practical approach to how we make use of the devices that we use to share data both within and outside the home and our businesses. I have my doubts on whether or not this will lead to a wave of cyber-attacks, but that is not to say that the vulnerability shouldn’t be taken seriously. It is incumbent upon all of us as users to guard our data and take all reasonable precautions to ensure that we are protecting our information as best as we are realistically able.”
Steve Lowing, Director of Product Management, Promisec:
“Generally, the Bash vulnerability could be really bad for systems, such as smart devices including IP cameras, appliances, embedded web servers on routers, etc… which are not updated frequently. The exposure for most endpoints is rapidly being addressed in the form of patches to all flavors of UNIX including Redhat and OS X. Fortunately for Microsoft, they avoid much of this pain since most Windows systems do not have Bash installed on them.
For vulnerable systems, depending on how they are leveraging the Bash shell the results could be grave. For example, a webserver that uses CGI for example would likely be configured to use Bash as the shell for executing commands and compromising this system via this vulnerability is fairly straightforward. The consequences could be to delete all web content which could mean Service level agreements (SLA)s are not met because of complete outage or deface the site which tarnishes your brand or even to be a point of infiltration for a targeted attack which could mean IP and/or sensitive customer information loss.
The IoT is the likely under the biggest risk since many of these devices and appliances are not under subject to frequent software updates like a desktop or laptop or server would be. This could result in many places for an attacker to break into and lay wait for sensitive information to come their way.”
Jason Lewis, Chief Collection and Intelligence Officer, Lookingglass Cyber Solutions:
“The original vulnerability was patched by CVE-2014-6271. Unfortunately this patch did not completely fix the problem. This means even patched systems are vulnerable.
Several proof of concepts have been released. The exploit has the ability to turn into a worm, so someone could unleash an exploit to potentially infect a huge number of hosts.”
Ron Gula, Chief Executive Officer and Chief Technical Officer, Tenable Network Security:
“Auditing systems for ShellShock will not be like scanning for Heartbleed. Heartbleed scans could be completed by anyone with network access with high accuracy. With ShellShock, the highest form of accuracy to test for this is to perform a patch audit. IT auditing shops that don’t have mature relationships with their IT administrators may not be able to audit for this.
Detecting the exploit of this is tricky. There are network IDS rules to detect the attack on unencrypted (non-SSL) web servers, but IDS rules to look for this attack over SSL or SSH won’t work. Instead, solutions which can monitor the commands run by servers and desktops can be used to identify commands which are new, anomalistic and suspect.”
Mike Spanbauer, Managing Director of Research, NSS Labs:
“Bash is an interpretive shell that makes a series of commands easy to implement on a Unix derivative. Linux is quite prevalent today throughout the Web, both as commerce platform and as commercial website platform. It happens to be the default script shell for Unix, Linux, well… you get the picture.
The core issue is that while initially the vulnerability highlights the ease with which an attacker might take over a Web server running CGI scripting, and ultimately, ‘get shell’ which offers the attacker the means to reconfigure the access environment, get to sensitive data or compromise the victim machine in many ways.
As we get to the bottom of this issue, it will certainly be revealed just how bad this particular discovery is – but there is a chance it’s bigger than Heartbleed, and that resulted in thousands of admin hours globally applying patches and fixes earlier this year.”
Contrast Security CTO and co-founder Jeff Williams:
“This is a pretty bad bug. The problem happens because bash supports a little used syntax for ‘exported functions’ – basically a way to define a function and make it available in a child shell. There’s a bug that continues to execute commands that are defined after the exported function.
So if you send an HTTP request with a referrer header that looks like this: Referer:() { :; }; ping -c 1 11.22.33.44. The exported function is defined by this crazy syntax () { :; }; And the bash interpreter will just keep executing commands after that function. In this case, it will attempt to send a ping request home, thus revealing that the server is susceptible to the attack.
Fortunately there are some mitigating factors. First, this only applies to systems that do the following things in order: 1) Accept some data from an untrusted source, like an HTTP request header, 2) Assign that data to an environment variable, 3) Execute a bash shell (either directly or through a system call).
If they send in the right data, the attacker will have achieved the holy grail of application security: ‘Remote Command Execution.’ An RCE basically means they have completely taken over the host.
Passing around data this way is a pretty bad idea, but it was the pattern back in the CGI days. Unfortunately, there are still a lot of servers that work that way. Even worse, custom applications may have been programmed this way, and they won’t be easy to scan for. So we’re going to see instances of this problem for a long long time.”
Tal Klein, Vice President of Strategy at Adallom:
“What I don’t like to see is people comparing Shellshock to Heartbleed. Shellshock is exponentially more dangerous because it allows remote code execution, meaning a successful attack could lead to the zombification of hosts. We’ve already seen one self-replicating Shellshock worm in the wild, and we’ve already seen one patch circumvention technique that requires patched Bash to be augmented in order to be ‘truly patched’. What I’m saying is that generally I hate people who wave the red flag about vulnerabilities, but this is a 10 out of 10 on the awful scale and poses a real threat to core infrastructure. Take it seriously.”
Michael Sutton, Vice President of Security Research at Zscaler:
“Robert Graham has called the ‘Shellshock’ vulnerability affecting bash ‘bigger than Heartbleed.’ That’s a position we could defend or refute, it all depends upon how you define bigger. Will more systems be affected? Definitely. While both bash and OpenSSL, which was impacted by Heartbleed, are extremely common, bash can be found on virtually all *nix system, while the same can’t be said for OpenSSL as many systems simply would require SSL communication. That said, we must also consider exploitability and here is where I don’t feel that the risk posed by Shellshock will eclipse Heartbleed.
Exploiting Heartbleed was (is) trivially easy. The same simple malformed ‘heartbeat’ request would trigger data leakage on virtually any vulnerable system. This isn’t true for Shellshock as exploitation is dependent upon influencing bash environment variables. Doing so remotely will depend upon the exposed applications that interact with bash. Therefore, this won’t quite be a ‘one size fits all’ attack. Rather, the attacker will first need to probe servers to determine not only those that are vulnerable, but also how they can inject code into bash environment variables.
The difference here is that we have to take application logic into account with Shellshock and that was not required with Heartbleed. That said, we’re in very much in the same boat having potentially millions of vulnerable machines, many of which will simply never be patched. Shellshock, like Heartbleed, will live on indefinitely.”
Mamoon Yunus, CEO of Forum Systems:
“The Bash vulnerability has the potential to be much worse than Heartbleed. Leaking sensitive data is obviously bad but the Bash vulnerability could lead to losing control of your entire system.
The Bash vulnerability is a prime example of why it’s critical to take a lockdown approach to open, free-for-all shell access, a practice that is all too common for on-premise and cloud-based servers. Mobile applications have caused an explosion in the number of services being built and deployed. Such services are hosted on vanilla Linux OS variants with little consideration given to security and are typically close to the corporate edge. Furthermore, a large number of vendors use open Linux OSes, install their proprietary functionality, and package commercial network devices that live close to the network edge at Tier 0. They do so with full shell access instead of building a locked-down CLI for configuration.
The Bash vulnerability is a wake-up call for corporations that continue to deploy business functionality at the edge without protecting their services and API with hardened devices that do not provide a shell-prompt for unfettered access to OS internals for anyone to exploit.”
Jody Brazil, CEO of FireMon:
“This is the kind of vulnerability that can be exploited by an external attacker with malicious intent. So, how do those from the Internet, partner networks or other outside connection gain access to this type of exposure?
An attack vector analysis that considers network access through firewalls and addresses translation can help identify which systems are truly exposed. Then, determine if it’s possible to mitigate the risk by blocking access, even temporarily. In those cases where this is not an option, prioritizing patching is essential. In other cases where, for example, where there is remote access to a vulnerable system that is not business-critical, access can be denied using existing firewalls.
This helps security organizations focus their immediate patching efforts and maximize staffing resources. It’s critical to identify the greatest risk and then prioritize remediation activities accordingly. Those are key best practices to address Bash or any vulnerability of this nature.”
Mark Stanislav, Security Researcher at Duo Security:
“While Heartbleed eventually became an easy vulnerability to exploit, it was ultimately time consuming, unreliable and rarely resulted in ‘useful’ data output. Shell Shock, however, effectively gives an attacker remote code execution on any impacted host with a much easier means to exploit than Heartbleed and greater potential results for criminals.
Once a web application or similarly afflicted application is found to be vulnerable, an attacker can do anything from download software, to read/write system files, to escalating privilege on the host or across internal networks. More damning, of course, is that the original patch to this issue seems to be flawed and now it’s a race to get a better patch released and deployed before attackers leverage this critical bug.”
Rob Sadowski, Director of Technology Solutions at RSA:
“This is a very challenging vulnerability to manage because the scope of potentially affected systems is very large, and can be exploited in a wide variety of forms across multiple attack surfaces. Further, there is no single obvious signature to help comprehensively detect attempts to exploit the vulnerability, as there are so many apps that access BASH in many different ways.
Because many organizations had to recently manage a vulnerability with similar broad scope in Heartbleed, they may have improved their processes to rapidly identify and remediate affected systems which they can leverage in their efforts here.”
Joe Barrett, Senior Security Consultant, Foreground Security:
“Right now, Shellshock is making people drop everything and scramble to fix patches. Security experts are still expanding the scope of vulnerability, finding more devices and more methods in which this vulnerability can be exploited. But no one has gotten hacked and been able to turn around and point and say ‘It was because of shellshock’ that I’ve seen.
If you have a Linux box, patch it. Now. Do you have a Windows box using Cygwin? Update Cygwin to patch it. And then start trying to categorize all of the ‘other’ devices on the network and determining if they might be vulnerable. Because chances are a lot of them are.
Unfortunately, vendors probably will never release patches to solve this for most appliances, because most [Internet-connected] appliances don’t even provide a way to apply such an update. But for the most part all you can do is try to identify affected boxes and move them behind firewalls and out of the way of anyone’s ability to reach them. Realistically, we’ll probably still be exploiting this bug in penetration tests in 8 years. Not to mention all of the actual bad guys who will be exploiting this.”
Until Next Friday…Have a Great Weekend!
Related Reading: What We Know About Shellshock So Far, and Why the Bash Bug Matters
Tor-Enabled Bifrose Variant Used in Targeted Attack
Posted on September 1, 2014 by Kara Dunlap in Security
A new variant of the Bifrose backdoor has been used in a cyberattack aimed at an unnamed device manufacturer, Trend Micro reported.
The threat, detected by the security firm as BKDR_BIFROSE.ZTBG-A, is more evasive than previous variants because it uses the Tor anonymity network for command and control (C&C) communications.
After infecting a device, the backdoor allows its masters to perform various tasks, including downloading and uploading files, creating and deleting folders, executing files and commands, capturing keystrokes, capturing screenshots and webcam images, terminating processes, collecting system information and manipulating windows.
“BIFROSE is mostly known for its keylogging routines, but it is capable of stealing far more information than just keystrokes,” Trend Micro threat response engineer Christopher Daniel So explained in a blog post. “It can also send keystrokes and mouse events to windows, which means that the attacker may be able to conduct operations as the affected user without having to compromise their accounts. For example, the attacker can log into internal systems or even send messages to other users in the network.”
While C&C communications via Tor can make the threat more elusive, the same communications can also be used by IT administrators to detect an attack. More precisely, they can identify malicious activity by monitoring the network for Tor traffic. Many organizations don’t use Tor for regular operations so any traffic associated with the anonymity network could indicate a cyberattack.
Another method recommended by Trend Micro for detecting Bifrose, in addition to the use of security solutions, involves checking for a file named klog.dat, which is used for the threat’s keylogging routines. Verifying network and mail logs could also help IT admins in detecting the malware.
Bifrose has been around since at least September 2008. One interesting campaign leveraging this particular threat was launched in 2010, when cybercriminals distributed the backdoor with the aid of a mail worm. The operation, dubbed “Here You Have,” was initially aimed at the human resource departments of organizations like NATO and the African Union. This old campaign demonstrates Bifrose’s potential for targeted attacks.
The “Here You Have” campaign was so successful that it caused a global outbreak.
OpenDNS Adds Targeted Attack Protection to Umbrella Security Service
Posted on July 9, 2014 by Kara Dunlap in Security
OpenDNS has enhanced its cloud-based network security service Umbrella with new capabilities designed to protect organizations against targeted attacks, the company announced on Tuesday.
The company says its monitoring systems are capable of detecting malicious traffic from the first stages of a potential targeted attack by comparing customers’ traffic to activity on OpenDNS’s global network. By providing predictive intelligence on the attackers’ network infrastructure, OpenDNS enables organizations to block attacks before any damage is caused.
Many organizations are capable of identifying single-stage, high-volume cyberattacks, but the “noise” generated by these types of attacks makes it more difficult to detect highly targeted operations, the company explained.
According to OpenDNS, its services address this issue by providing real-time reports on global activity and detailed information for each significant event. The reports can be used by enterprises to identify ongoing or emerging targeted attacks based on whether or not the threats have a large global traffic footprint, or if they’re detected for the first time.
In order to make it easier for security teams to investigate an incident, OpenDNS provides information on the users, devices and networks from which malicious requests are sent. Information on the attackers’ infrastructure can be useful for predicting future threats and for blocking components that are being prepared for new attacks.
“Enterprises today are challenged to keep up with the volume of attacks that are targeting their networks. Not only is the efficacy of today’s security tools declining, but when they do identify a threat they lack the context that is critical to blocking it,” said Dan Hubbard, CTO of OpenDNS. “The ability to determine the relevance and prevalence of an attack is key to prioritizing response, remediating infected hosts, and understanding the scope of the threat.”
The new capabilities are available as part of the Umbrella service based on a per user, per year subscription.
Automated Traffic Log Analysis: A Must Have for Advanced Threat Protection
Posted on May 8, 2014 by Kara Dunlap in Security
If there is a silver lining to the series of high-profile targeted attacks that have made headlines over the past several months, it is that more enterprises are losing faith in the “magic bullet” invulnerability of their prevention-based network security defense systems.
That is, they are recognizing that an exclusively prevention-focused architecture is dangerously obsolete for a threat landscape where Advanced Persistent Threats (APTs) using polymorphic malware can circumvent anti-virus software, firewalls (even “Next Generation”), IPS, IDS, and Secure Web Gateways — and sometimes with jarring ease. After all, threat actors are not out to win any creativity awards. Most often, they take the path of least resistance; just ask Target.
As a result of this growing awareness, more enterprises are wisely adopting a security architecture that lets them analyze traffic logs and detect threats that have made it past their perimeter defenses – months or possibly even years ago. It is not unlike having extra medical tests spot an illness that was not captured by routine check-ups. Even if the news is bad (and frankly, it usually is), knowing is always better than not knowing for obvious reasons.
m
However, while analyzing traffic logs is a smart move, enterprises are making an unwelcome discovery on their road to reliable threat detection: manual analytics is not a feasible option. It is far too slow, incomplete, expensive, and finding qualified professionals in today’s labor market is arguably harder than finding some elusive APTs; at last look on the “Indeed” job board, there were over 27,000 unfilled security engineer positions in the US alone.
The average 5,000 person enterprise can expect their FW/IPS/SWG to generate over 10 gigabytes of data each day, consisting of dozens of distinct incidents that need to be processed in order to determine if and how bad actors have penetrated the perimeter. All of this creates more than a compelling need for automated analysis of traffic logs, which allows enterprises to:
● Efficiently analyze logs that have been collected over a long period of time
● Process logs at every level: user, department, organization, industry, region
● Correlate the logs with malware communication profiles that are derived from a learning set of behaviors and represent a complete picture of how malware acts in a variety of environments
● Use machine learning algorithms to examine statistical features, domain and IP reputation, DGA detection, and botnet traffic correlation, etc.
● Adapt by using information about different targeted and opportunistic attacks from around the world (“crowdsourcing”) in order to get a perspective on the threat landscape that is both broader and clearer
● Integrate credible and actionable threat data to other security devices in order to protect, quarantine, and remediate actual threats
● Get insight on how the breach occurred in order to aid forensic investigations and prevent future attacks
With this being said, does this mean that enterprises will finally be able to prevent 100% of the targeted attacks? No; there has never been a magic bullet, and this is unlikely to change in our lifetime. Any belief to the contrary plays directly into the hands of threat actors.
However, automated traffic log analysis can help enterprises reduce the number of infections, including those that they do not know about, yet are unfolding in their networks right now, before the compromise becomes a breach. And considering that it only takes one successful breach to create a cost and reputation nightmare that can last for years, the question is not whether automatic analysis makes sense, but rather, how can enterprises hope to stay one step ahead of the bag guys without it?
Related Reading: The Next Big Thing for Network Security: Automation and Orchestration
Related Reading: Network Security Considerations for SDN
Related Reading: Making Systems More Independent from the Human Factor
Related Reading: Software Defined Networking – A New Network Weakness?