The news is rife with stories about the "Bash" bug, which hackers can exploit to take over computers and wreak all manner of havoc. Here's what bankers need to know to keep Bash at bay.
In a nutshell, what is Bash?
It's a commonly used piece of code that tells a computer what to do (e.g. turn on, turn off). It exists on hundreds of millions of computers worldwide running Unix, Linux and Mac OS X operating systems, especially older ones. (For instance, it's on most home network routers.) Due to a recently discovered flaw, a hacker who can access a computer or device and slip in malicious code can potentially take over the machine and make it do just about anything make it part of a botnet, steal customer account information, what have you. Bash is open source software that has been maintained by one person for 25 years.
How seriously should I take this threat?
In a word: very.
"This is a vulnerability that's been out there since 1989, so it's hard to get too excited about something that's existed that long," said Shirley Inscoe, a senior analyst at Aite Group. "But hackers are creative and they've recently started targeting this." One of her biggest concerns about Bash is that about 2% of consumers use computers that run Linux or Unix and many use Mac OS X. Those machines can be taken over and used in a DDoS attack that can be hurled at a bank.
The National Institute of Standards and Technology, which tracks cyber vulnerabilities, has rated Bash a 10 out of 10 in seriousness.
This is a data-driven rating format, points out Dan Ingevaldson, the chief technology officer of Easy Solutions, a provider of fraud prevention software. "It's based on quantitative information, it's not [subjective] like Dancing with the Stars," he said. "This is based on the prevalence of the vulnerability, the ease of exploitation, and how obvious the exploitation is or isn't."
It's also a serious threat because it's simple to use and therefore appealing to cybercriminals, he said. "Hackers hate vulnerabilities that are complex because they're just as likely to crash the target as exploit it."
The Bash flaw also can be used to inflict a lot of damage, more so than Heartbleed. "You can take over a server with it," Ingevaldson said. "[With] Heartbleed, you can't. It will let you maybe access a password if you're lucky. This lets you run commands."
Hackers have begun actively scanning for Bash they can scan the entire Internet in a few hours to find the low-hanging fruit, such as vulnerable web servers and administrator portals for routers and VPN systems.
"There's a lot of hyperbole out there, but unfortunately a lot of it is well placed," Ingevaldson said. "It's really easy for someone to take over a lot of machines right now. The timing on this one is extraordinarily critical."
OK, so where is a bank likely to have this vulnerability?
Any system that runs Unix, Linux or Mac OS X operating systems is likely to have Bash, and almost all banks use Linux and Unix somewhere. (They're less likely to use Macs, but the third-party website designers they hire often use them.)
Some banks' legacy core systems run on Linux or Unix, and therefore need to be tested for Bash.
Certain closed-circuit television security cameras watching ATM lobbies and drive-through areas have Linux as the embedded OS, according to Alan Dundas, vice president of product architecture at the security software company Authentify.
"It's entirely possible they are somehow connected to your network for backup and archive," he added, which is where Bash becomes more dangerous. Most ATMs do not use the Linux operating system, but banks that build their own ATM software often use Linux, he said.
Building control systems, such as thermostats and automatic light switches, are also likely to use Linux, according to Dundas.
So are web servers, which are a bigger concern because they are public-facing and therefore accessible to hackers.
What are the best ways of protecting a bank against Bash?
Securing access to the bank's networks is critical.
"The good news is that you still need access to the system to be able to exploit the Bash flaw," Dundas said. "If a hacker has already penetrated your network and has been doing reconnaissance, this gives them something to hunt for and exploit. If your organization has done a good job and no unauthorized users have yet to gain access, you have time to patch."
Scanning for Bash and updating the code with a patch is the main thing IT administrators need to do. But this is not as simple as it may sound, Ingevaldson noted, because Bash can't be scanned for remotely the way some other software flaws can. Each system needs to be individually tested.
Bank IT and security departments might be better off identifying the vendors they use that are vulnerable and implementing patches as quickly as possible. And they're going to have to triage: "If you're Citigroup, you can't patch 100,000 systems in a day," Ingevaldson said.
Does this discovery mean banks should beware of open source software?
This points to an age-old debate.
"The question banks have to ask themselves is, do they rely on cheap open source material that will eventually have infections found out and fixed, but they'll be publicized, or do they try to do it themselves in a way that is perhaps suboptimal and potentially buggy but the flaws won't be as public?" said Daniel Latimore, senior vice president at the research firm Celent.
If a bank uses proprietary software containing bugs, he said, "someone could still find them, but they'd have to look in 10 different individual banks rather than having the Bash bug out there to seize on."
But some say avoiding open-source would be like trying to unscramble an omelet.
"That's like saying 'maybe we shouldn't breathe because we know the air is polluted,'" Inscoe said. "Open source software is out there, every bank uses it, and so much has been developed based on it that I don't think we're ever going to get away from open source software. I think banks have to constantly be vigilant about all these issues."
Small banks are much more vulnerable than large ones with well-staffed security departments, she noted.
Ingevaldson points out that there are closed-source systems that use Bash, too.
The more information about vulnerabilities that's out there, the more hackers can exploit. Would it be better for the industry to be vocal or quiet about the Bash bug?
The software community handled this problem discreetly, some say. "The way they went about it, trying to fix as much as they could quietly, then being public about it once the remediation had taken place, is absolutely right," said Latimore. "Part of the whole foundation of open source is transparency done smartly, particularly for something of this level of severity."