Banks: Beware of These Shellshock Risks

Why Vulnerability Scanning, Customer Education Are Essential
Banks: Beware of These Shellshock Risks

Shellshock: What unique risks does it pose for banking institutions?

See Also: Data Security Risk: A CISO's Perspective

Experts say most banks' online- and mobile-banking platforms aren't likely vulnerable to attacks that exploit the Bash flaws known as Shellshock. But they say vulnerability scanning and customer education will be critical, as institutions work to ensure they find and eradicate all Shellshock flaws.

The risk posed by Shellshock hasn't been missed by banking regulators, either. On Sept. 26, the Federal Financial Institutions Examination Council issued an alert about Shellshock, a material security vulnerability found in Bourne-again shell system software, known as Bash - a common command-line used in Linux-based, Unix-based and Apple's Mac OS operating systems.

A primary concern is Bash's ubiquity: The command shell exists all over the Internet, from Web servers and e-mail servers to physical security systems and beyond.

But security experts, though still investigating exactly which systems may be at risk, so far report minimal online- and mobile-banking concerns. Banks should, however, beware of potential Bash exploits linked to e-mail servers and devices, warns Mike Smith, director of Akamai's Computer Security Incident Response Team.

Banking regulators also have warned of possible fraud that could be linked to any number of Bash exploits, and say banking institutions must regard every Shellshock vulnerability as a serious threat (see How to Mitigate Shellshock Risks).

With that in mind, security experts recommend that banks and credit unions focus on Shellshock-related remediation avenues.

First, banks should be scanning their networks for Bash and then determine how they can upgrade the Bash script where it is present. Patching is critical, too. But banking institutons and others should test vendor-provided patches to ensure they work as advertised.

"Several patches have been put out to solve various pieces of the vulnerability," Smith says. "The first patch blocked the exploit sequence but didn't anticipate a couple of other ways that the exploit could be encoded. A later patch disables the function export ability of bash, which closes the vulnerability, but will break scripts that rely on that feature."

Another important consideration is customer education. Banks and credit unions should explain the risks Shellshock poses for home devices, such as routers. But such education has its limits, experts say, especially for Internet-connected devices that are no longer supported or for which manufacturers have yet to release patches.

Compromise of Online Banking?

Overall, however, financial institutions are no more at risk than any other business that uses Bash and utilizes common gateway interface scripts. CGI, to generate dynamic content on Web pages and Web applications, says Tom Kellermann, chief cybersecurity officer of online security firm Trend Micro.

"The greatest threat to FIs is the exploitation of Web servers that would allow for those websites to become watering holes, which would then unleash a crime wave upon their constituency," he says. Watering hole attacks involve the injection of malicious software onto websites, such as online banking sites, which, in turn, then infect site visitors' computers with malware. To date, however, "it's not like Shellshock is specifically targeting banking software."

Banks shouldn't face elevated Shellshock risks, compared to other sectors, Kellermann says. "But they are just targets, in general; like everything else."

In fact, Don Jackson, director of threat intelligence for online security firm PhishLabs, contends that most online banking sites won't be susceptible to Shellshock. CGI applications implemented using Bash have become "exceedingly rare," he says, and are practically unheard of among Internet banking applications today.

"Although some advances have been made to prolong the useful life of the old CGI standard, performance and scalability is low compared to more modern alternatives," he says. "The Bash shell's language is a poor choice for virtually any Web application that's even moderately complex, and even using it to simply call other programs on the host server can cause performance hits and introduce security holes that limit the life of a webserver in the hostile network environment of the public Internet."

Akamai's Smith agrees, noting that the presence of CGI scripts does not, necessarily, mean Bash is being used. "There are still some online-banking sites that use CGI at sign-in or log-on, but that doesn't mean they are using Bash," Smith says. "And most online-banking sites today don't even use CGI because there are much easier ways to do it."

Mobile Not Vulnerable?

When it comes to mobile banking and Shellshock risks, institutions should review server-side and mobile-application coding, Smith says. While the vast majority of mobile apps won't be impacted, Shellshock does have the potential to adversely affect the server side, but only if the server uses an unpatched Bash in CGI, he adds.

Jackson says, however, that because attack methods and payloads vary according to attacker's capabilities and motives, banks should not ignore possible mobile risks. "Make it a priority to discover and patch every instance of Bash in their environment, whether it's likely to be exposed via one particular vector or not," he says.

But the risk to mobile is low, Jackson agrees. "Most mobile banking apps interact with Web services, and these are typically implemented using modern frameworks far removed from old, die-hard Web technologies, like CGI," he says. "I'd think the likelihood that those systems would be exposed to remote exploits of Shellshock would be even less than that for systems using traditional, browser-based online banking using interactive Web applications that rely more on older technologies."

Network Scanning

Nevertheless, beyond those Web concerns, researchers say banking institutions should assume any Linux/Unix servers and devices with Bash script could be at risk from Shellshock.

As a result, banks and credit unions should have automated scanning in place to detect overlooked vulnerabilities that may exist in legacy code, and start patching Bash-using systems immediately.

"Testing for the use of CGI for Web server applications and for vulnerable versions of certain common CGI scripts is part of virtually every automated vulnerability assessment solution on the market," Jackson says. "Many providers of those solutions have already incorporated checks for Shellshock as part of their Web scanning functions. Beyond assessing the Web vector, these tools can also be configured to check the version of Bash installed on the bank's systems and alert on any vulnerable versions they find, regardless of whether the Shellshock vulnerability is exposed via the Web server.

That scanning should cover all possible vectors, Jackson says, including vulnerable secure shell configurations and attacks using dynamic host configuration protocol - just to note two examples.

But Chris Morales, practice manager of architecture and infrastructure at NSS Labs, says banks should not rely too heavily on Web application scanning to ensure they've detected all presence of Bash. "Nothing is a guarantee without manual testing and verification," he says - a point echoed by Smith.

"Really, I think the best way is to find the servers that have Bash and fix it," Smith says. "It's really a server-by-server issue, rather than a Web scan issue."

Kellermann advocates that approach as well, and also recommends adopting a different shell to solve related script vulnerability problems, noting that good alternatives to Bash are available, including shell codes such as Almquist and Debian Almquist - better known as Ash and Dash. Both have been around since the late 1980s and early '90s. In fact, many systems are already using these shell codes now, and thus won't be susceptible to Shellshock-related attacks.

Customer Education

Neira Jones, an independent cybercrime and payments fraud adviser, says in addition to working closely with security and network vendors, banking institutions should educate their customers about risks related to Shellshock.

"Financial services institutions should also play a role in education and awareness by informing their customers that they should be watching out for firmware updates from the manufacturers of their consumer devices, such as broadband routers, modems, etc., and use up-to-date anti-virus software and refrain from sharing sensitive personal information online for the next little while unless absolutely necessary," she says. "These things potentially present a large and unquantifiable attack surface." But until manufacturers issue patches for those devices, or users cease using unsupported devices, that attack surface may persist well into the future.


About the Author

Tracy Kitten

Tracy Kitten

Executive Editor, BankInfoSecurity & CUInfoSecurity

A veteran journalist with more than 18 years' experience, Kitten has covered the financial sector for the last 11 years. Before joining Information Security Media Group in 2010, where she now serves as the Executive Editor of BankInfoSecurity and CUInfoSecurity, she covered the financial self-service industry as the senior editor of ATMmarketplace, part of Networld Media. Kitten has been a regular speaker at domestic and international conferences, and was the keynote at ATMIA's U.S. and Canadian conferences in 2009. She has been quoted by CNN.com, ABC News, Bankrate.com and MSN Money.




Around the Network