Archive for September 28, 2014

Shellshock (CVE-2014-6271 and CVE-2014-7169) is the name of a bug affecting the Gnu Bash (Bourne-again shell) command-line shell, which can be used on many Linux and UNIX operating systems, as well as Mac OS X. It does not affect Windows computers unless you’ve installed Bash with something like Cygwin. While it’s unlikely that most consumer computers will be targeted, it’s a good idea to watch for updates for operating systems, firewalls, routers, switches, modems, printers, and household items that can be assessed over the Internet–TVs, thermostats, IP cameras, and other items.

It is already being exploited by worms and other malware.

Cisco, Red Hat, Debian, and Ubuntu have already issued updates. The first patch issued did not completely fix the problem, so make sure you update to the version that addresses CVE-2014-7169 as well as CVE-2014-6271. Apple has not issued any updates as of September 28, 2014.

This bug has been around for a very long time; the latest (safe) Bash version is 3.2.53.  Brian J. Fox wrote Bash in 1987 and supported it for five years, and then Chet Ramey took over support–his unpaid hobby. Mr. Ramey thinks Shellshock was accidentally added in 1992.

We have a Macbook that was running a vulnerable version of Bash. I manually updated Bash per this article.

According to Qualys, here’s how to test for the vulnerabilities; at the command line, paste the following line (make sure this line is exact):

env var='() { ignore this;}; echo vulnerable’ bash -c /bin/true

If you have a vulnerable version of bash, the screen will display “vulnerable.” Just to be safe after updating, check the bash version by typing:

bash –version

Vulnerable versions will be before 3.2.53.

If you applied a patch before Friday, you might have a less-serious version of the error, which you can check by typing the following:

env X='(){(a)=>\’ bash -c “echo date”; cat echo; rm -f echo

This line will display the date if bash has not been completely patched.  After patching, you will get an error when running this command.

According to KrebsOnSecurity.com, Jimmy Johns aren’t the only restaurants to get caught in this breach, which lasted from June 16 through mid-September (dates vary at some locations). Many small restaurants use Signature Systems PDQPOS point-of-sale systems. A total of 216 Jimmy Johns and 108 other restaurants are affected because “an authorized person gained access to a user name and password that Signature Systems used to remotely access POS systems.” This access allowed the attacker to install malware to steal payment card data, containing the cardholder’s name, card number, expiration date, and verification code from the magnetic stripe of the card.

I wonder if Signature Systems changed their passwords on a regular basis? Probably not. Did they use two-factor authentication? Long and strong passwords? Did they conduct employee training on anti-phishing techniques?

Unfortunately, as of October 28, 2013, PDQPOS was only acceptable for pre-existing deployments. So it’s possible that some of these restaurants may receive fines if the system was installed after that date.