BASH bug vulnerability?

[TheUberOverLord]

There are now Seven not Six any longer "Bash" AKA Shellshock vulnerabilities which have been located as of 10/04/2014 4:00 PM CTD time.

For proper testing methods. Including command line tests for all Seven "Bash" known exploits. Please see this:

https://shellshocker.net/

More here:

http://www.news.com.au/technology/ex...-1227070183296

http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

Don

[TheUberOverLord]

Here are some more in depth details about this vulnerability:

http://seclists.org/oss-sec/2014/q3/650

http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

https://www.webmaster.net/shellshock-fix-bash-vulnerability-bug-and-determine-if-your-system-is-vulnerable/

Don

[Uncle Michael]

BASH bug vulnerability?

How vulnerable are devices with embedded UNIX systems? I'm thinking of routers, IP cameras, and the like? Should I be worried?

[vasrc]

Good question, but no simple answer. Reading some of the related lists (Nanog, Seclist) it sounds like many of the embedded devices use a bash variant and not the full blown (compromised) bash binary.
Our two servers have had a couple of nibbles looking for access, but they were patched as soon as Redhat had a patch available, so nothing happened.

Problem is, lots of embedded devices are not updateable (or very difficult to do), so if a serious bug is found, very little can be done to fix it..

Z

http://seclists.org/oss-sec/2014/q3/index.html
http://mailman.nanog.org/pipermail/n...er/thread.html

[Uncle Michael]

Do you know which IP cams need it? (Is there a published list?)
Are there patches available yet? Where?

[TheUberOverLord]

Do you know which IP cams need it? (Is there a published list?)
Are there patches available yet? Where?

This becomes somewhat complicated to answer.

The issue is a vulnerability found in the "Bash" program:

http://en.wikipedia.org/wiki/Bash_(Unix_shell)

Most embedded devices run some form of Unix/Linux and even if "Bash" is not used as the default shell for those devices. It maybe used from time to time by the device and can be invoked as needed. If it's present in that embedded devices firmware files, as an example.

If you have for example ROOT access to a device or system. You would be able to determine if "Bash" as a program is present. That said. You may not easily be able to determine what functions a device uses "Bash" for and when. A device could use "Bash" for specific or all .CGI commands, DHCP services and other things. So unless you knew/know how the device uses "Bash" and when. It's becomes complicated to determine when "Bash" is used. Unless you had access to the entire source code of that device and any scripts it uses.

Additionally. If the device is firmware based and you can't build your own firmware for that device but you have say FTP or Telnet to that device. You might be able to manually install a new version of "Bash" on that device. But, if you were to re-flash firmware on that device and "Bash" was not updated. You would re-infect that device by using a non-patched version of "Bash".

What maybe confusing to many is that even if a device does not use "Bash" as the devices default shell program. That device may use "Bash" from time to time for some things. So without having complete source code or Root access to a device using Telnet or FTP or SSH methods. It might be impossible to determine if that device even has "Bash" installed on it and/or when "Bash" could be used for that device.

This is what makes this issue so complex. Because in many cases you are at the mercy of the device manufacture to release new firmware for a device vs. doing the fix yourself like you could say on a Linux/Unix web server and then simply install a new copy of "Bash".

So far, two different "Bash" versions have been released as fixes. There may more to come. Depends on if other issues are located soon with "Bash".

The issue becomes that in many cases you might not be able to determine if your embedded device even has "Bash" installed or when or if it uses it and what for. So far, there is no list for what embedded devices are at risk and most likely it will never be produced. What's terribly bad about this is that at some point vulnerable devices could be abused to infect other things. Making the device part of a "BOT-NET" for example has already been done to create DDOS attacks.

So, what the future holds in store will be interesting at best and a nightmare at worse. Because many manufacturers may not take the time to issue firmware upgrades and even if they do they might not do it for older embedded devices. Leaving those devices forever to be abused and abuse others.

As one simple example. I don't know of a single Router/AP manufacturer that has announced they have a firmware upgrade for a Router/AP. While many if not most Router/APs use BusyBox as their Operating System. Some must still be using other flavors of Unix/Linux where "Bash" is present and being used for services that are exposed locally or to the Internet from that device. Such as CGI or DHCP services. At least at this point, not much is being heard from embedded device manufactures on if their devices are vulnerable to this. I hope that changes soon.

Bottom line there are two requirements for this "Bash" BUG to be abused. The embedded device must be using "Bash" and whatever it uses "Bash" for must be exposed to the Internet or locally, so that others can abuse it. If one of those two things is not present, then this vulnerability can't be abused. Some Router/APs may use "Bash" for DHCP services or in their Admin menus when all or specific menu options are used from those menus.

That said. There are online tests you can try to see if your embedded device is exposed to this vulnerability. But you may have a device that is NOT using "Bash" for the CGI command you use to test with. So, one can't use a single CGI command for a device and prove that other CGI commands for that same device don't use "Bash".

One Online Test For This Vulnerability:

http://shellshock.brandonpotter.com/

Note: The average Cpanel for Websites only had two CGI commands in their menus, that use "Bash". So if you used the above tester on the Cpanel CGI commands that don't use "Bash". You would think all is well and you are protected. When you are/were not. Because of this one would need to check every possible thing that one could access locally and remotely from that device. In many cases "Bash" may be invoked for a command without User Credentials even being parsed yet. So one can't assume that if someone remotely uses a command for a device that they would first need to become authorized by that device before bad things could happen.

Examples:

Say you have an embedded device that is using a vulnerable version of "Bash" and it handles .CGI commands for that device. If you can only access that device using a VPN. Then nobody could abuse that device even with the "Bash" vulnerability without having access to that VPN first.

Say you have the same device above but it is not exposed to the Internet and used locally. Nobody could abuse that device unless they had local network access to that device.

Say you had a device that does not use "Bash" and was exposed to the Internet. Then there is nothing to be abused because "Bash" is not present or being used for services like CGI or DHCP or other things which could be exploited.

So the million dollar question is: "Does a embedded device even use "Bash" and if it does, can others access the services that device offers locally or remotely that use "Bash" to abuse this vulnerability?"

Don

[Uncle Michael]

Don,
I greatly appreciate the very comprehensive response, but as you so eloquently point out, for most of us - even skilled technical people - what is missing is a detailed understanding of the way specific devices operate and hence their vulnerability to an exploit using the bug.

What I'd like to see is a list of vulnerable devices based on a comprehensive analysis by the device manufacturers, quickly followed by an easily implemented patch process that mere mortals can follow. Many of these devices, after all, are likely in the hands of consumers rather than organizations with skilled IT departments.

The best outcome, of course, would be to learn that most devices are not affected (kitchen appliances, IP cameras, for example) and that patches can be pushed to the most troublesome devices, like home and small business network infrastructure.

Is there any evidence that manufacturers are stepping up?

[Pete]

Updated the ZeeLite today...

Updatable package information
Package name bash
Update system APT
Package description armhf GNU Bourne Again SHell
Current state New version 4.2+dfsg-0.1+deb7u3
Installed version 4.2+dfsg-0.1
Available version 4.2+dfsg-0.1+deb7u3
Installation source Wheezy

[TheUberOverLord]

QNAP NAS Front-Ends have fixes for Bash AKA Shellshock now:

http://forum.qnap.com/viewtopic.php?...1370dedca360ee

http://forum.qnap.com/viewtopic.php?f=187&t=98188

http://forum.qnap.com/viewtopic.php?...1370dedca360ee

HomeTroller Zee Front-End has fixes for Bash AKA Shellshock now:

http://board.homeseer.com/showpost.p...12&postcount=1

Synology Front-End has fixes for Bash AKA Shellshock now:

https://www.synology.com/en-global/s...ash_shellshock

Synology support forum: http://forum.synology.com/enu/index.php

Note: If you have added Optware/Entware installed on any of the above devices. You should use the support forums for those devices. Above. If you have Optware/Entware installed in your Router/AP as a custom add-on you should also go to the support forum for that Router/AP because both Optware/Entware do use "Bash" even if the Router/AP does not use "Bash" as its default shell and both Optware/Entware can be vulnerable to these "Bash" vulnerabilities. Depending on how you set them up and any custom scripts you may allow to access them remotely.

Netgear Front-Ends: ReadyNAS, ReadyDATA, ProSECURE UTM firewall and ProSAFE FVS318N have fixes for Bash AKA Shellshock now:

http://kb.netgear.com/app/answers/detail/a_id/25703

OpenVPN Issues to be aware of:

http://www.theregister.co.uk/2014/09...ck_researcher/

VMware Issues to be aware of:

http://s1.securityweek.com/vmware-re...shellshock-bug

Cisco/Oracle Issues to be aware of:

http://www.computerworld.in/news/cis...-by-shellshock

McAffee Products has fixes for Bash AKA Shellshock now:

https://kc.mcafee.com/corporate/inde...SB10085#status

Symantec Products has fixes for Bash AKA Shellshock now:

http://www.symantec.com/outbreak/?id=shellshock

Avaya Products has fixes for Bash AKA Shellshock now:

https://support.avaya.com/helpcenter...26131554370002

Kace Endpoint Systems Management Products has fixes for Bash AKA Shellshock now:

http://www.kace.com/support/resource...ail?sol=133716

Riverbed Products has fixes for Bash AKA Shellshock now:

https://supportkb.riverbed.com/suppo...tent&id=S24997

Untangle Products has fixes for Bash AKA Shellshock now:

https://support.untangle.com/hc/en-u...ts-vulnerable-

pfSense Products has fixes for Bash AKA Shellshock now:

https://www.pfsense.org/security/adv...8.packages.asc

Information for Operating Systems other then Unix/Linux as well as more detail

Android Not vulnerable unless "rooted":

http://seclists.org/fulldisclosure/2014/Oct/25

Apple What to understand and know about Bash AKA Shellshock vulnerabilities:

http://support.apple.com/kb/HT6495

http://mac-how-to.wonderhowto.com/ho...-os-x-0157606/

Windows What to understand and know about Bash AKA Shellshock vulnerabilities and their derivatives:

http://threatpost.com/shellshock-lik...windows/108696

http://grandstreamdreams.blogspot.co...d-linkage.html

Additional Bash Flaws Show Weakness of Original Shellshock Patch now:

http://www.infosecurity-magazine.com...laws-original/

Bash AKA Shellshock vulnerability determined to have been present since at least 12/08/1991. Investigation continues on how far back it goes:

http://www.openwall.com/lists/oss-security/2014/10/04/2

Outstanding known not public vulnerabilities

I use a standard protocol when I encounter vulnerabilities with devices/software which I have used for many years when doing security research testing. I allow the Manufacturers/Vendors 30 days before I go public with my findings. Worse case I may give a 15 day extension if the Manufacturer/Vendor works with me, to help better prove they are actively working on a fix. Example:

http://www.kb.cert.org/vuls/id/265532

I am aware of three other embedded devices which include other Front-Ends and one IP Camera. Which while testing I found had exposure to the current "Bash" vulnerabilities and am waiting on responses from the Manufacturers/Vendors. Based on each Manufacturers/Vendors response will help me decide if I will create a formal CVE for the vulnerability. Which sometimes I don't do and work with the Manufacturer/Vendor privately. If they don't play games. If they do play games, then I do file a formal CVE as the above CVE example link shows. Foscam has never played any games with me other than the first time. Which is sometimes normal. Since then, I have worked privately with Foscam to fix many vulnerability issues I have found since. Personally, I would rather work privately then file a formal CVE.

I will add other Front-Ends and/or IP Cameras to this list as their Manufacturers/Vendors provide fixes that I locate and find here as well.

Don

[Uncle Michael]

Don,
Thanks for the update. The OpenVPN issue is the most troubling for me because it is very broadly used as an embedded function in devices like routers and other consumer accessible, easy to set up VPN functionality. In the past I've used my router's VPN capability. It is based on OpenVPN, but I have no idea if it suffers from the vulnerability in the link you provided. Apart from waiting and hoping the manufacturer will address any problems, what other recourse does someone like me have?

[TheUberOverLord]

Don,
Thanks for the update. The OpenVPN issue is the most troubling for me because it is very broadly used as an embedded function in devices like routers and other consumer accessible, easy to set up VPN functionality. In the past I've used my router's VPN capability. It is based on OpenVPN, but I have no idea if it suffers from the vulnerability in the link you provided. Apart from waiting and hoping the manufacturer will address any problems, what other recourse does someone like me have?

Mike,

Please see these they me be helpful for the OpenVPN issue:

http://threatpost.com/openvpn-vulner...-vulnerability

http://www.pcworld.com/article/26903...erability.html

I would also send a message to support folks and voice your concerns. Because this is nothing to leave "As Is" when a Router/AP is at risk. If they don't respond quickly could you disable that function while you are waiting? Not a solution, but it may help some to block any abuse from taking place. That said. Not knowing the Router/AP brand and model. There maybe other abuses as well that could be executed. Depending on if that Router/AP is using "Bash" for other things as well as OpenVPN.

Don

[Uncle Michael]

Don,
The problem I'm having is that all the communications, including the links you provided, are aimed at people who incorporate the OpenVPN functionality. They all say there are multiple ways to configure the system, and some of those configurations are vulnerable, but other are not.

As an end user, I see no accessible way to determine whether the device I am using is vulnerable or not. As you suggest, I simply assume it is, and have disabled the VPN server. That's okay for now, but if I'm traveling it will be less satisfactory.

FWIW, I'm using an ASUS router. I haven't been able to find any specifics for it aside from being sure the firmware is updated to the latest version. But that version predates this problem.

[TheUberOverLord]

Don,
The problem I'm having is that all the communications, including the links you provided, are aimed at people who incorporate the OpenVPN functionality. They all say there are multiple ways to configure the system, and some of those configurations are vulnerable, but other are not.

As an end user, I see no accessible way to determine whether the device I am using is vulnerable or not. As you suggest, I simply assume it is, and have disabled the VPN server. That's okay for now, but if I'm traveling it will be less satisfactory.

FWIW, I'm using an ASUS router. I haven't been able to find any specifics for it aside from being sure the firmware is updated to the latest version. But that version predates this problem.

What model number?

Have you installed custom firmware in this Router/AP or is it stock firmware?

Don

[Uncle Michael]

What model number?

RT-N56U

Have you installed custom firmware in this Router/AP or is it stock firmware?

Stock

[TheUberOverLord]

RT-N56U
Stock

I can't locate any information that says this router model uses "Bash".

That said, it's possible.

I do know that many devices even when they use OpenVPN may use other shells like Ash, as on example and not "Bash". So it's possible to have a version of OpenVPN that is not exposed to this "Bash" exploit.

Don