Shell Shock is a vulnerability in bash (the Bourne shell) used on Linux and many Unix systems that allows injection of shell commands into environmental variables.
This is a significant security problem for any web server which uses CGI scripts as these are typically run directly the default shell environment, and it is possible to specify the environmental variables as a part of the invoking URL. Over 50% of all web servers run on Linux environments and bash is the default in the majority of these environments.
The Shell Shock issue affects Linux, Unix, Mac OS/X and vmWare and any Windows system which has the Cygwin environment installed on it or any version of bash compiled for Windows. This could also affected any embedded system which has a web interface and which uses one of the above operating systems.
A patch has been released by the maintainer of bash which addresses the simple to test exploit. However, this patch contains flaws which still allow exploitation of the same loop hole using specially crafted characters. At the time of writing, no patch exists to address these flaws. Additionally, Apple and vmWare have not released patches to address the issue on their operating system. It is possible to compile the latest version of bash on Mac OS/X however this requires Xcode or another compiler be installed on the machine to
Please be aware the detection solution provided here for checking for the bash vulnerability only check for the simple test case, not the more complex test case. This only check for the default shell instance. You must audit your machines for every instance of bash which the supplied report will do for Linux and Windows machines, but not OS/X (as only .app files are audited on OS/X).
There are three agent procedures provided. The first is a detection script which audits the version of bash installed on the default path and writes it to the procedure log entry on Linux and OS/X machines. It additionally runs the simple test case script on Linux machines, and sends the administrator running the script an email if a machine is found to be vulnerable. There are also two agent procedures, for Red Hat (using yum) and Debian (using apt-get) which update bash to the latest version available.
To run the agent procedure, you need to create a custom audit field 'Shell Shock'. You must modify the report to display this custom audit field, which will depend on the number of custom audit fields you are already using on your Kaseya VSA. You need to run the detection agent procedure against all your agents in order to populate the information used by the report.
An example of the report output is:Shell Shock Vulnerability Analysis.pdf
Import the following XML using the import/export centre under the System tab: Shell_Shock_Vulnerability.xml
The following is updated agent procedures to use the new detection routine that Red Hat has provided at https://access.redhat.com/articles/1200223 which detects both vulnerable versions of bash and partially patched versions. You will need to create a custom audit field 'Shell Shock' on your Kaseya server.
Procedure Folder Shell Shock Vulnerability.xml
It also now works on OS/X and creates an alert on your Kaseya notification bar informing you of when a vulnerable machine is detected.
The patching routines will now issue the final patch for bash which corrects the vulnerability. You will need to rerun these if you patched to the interim version (which will be highlighted by the detection routine).
Thanks for doing this.
Thanks for this procedure its brilliant and works great with the custom filed. Can I just check how you created that report in your download? was there an audit report part you used?
The audit part is an audit of all Installed Applications which contain the string 'bash'.
Please note that there continue to be shell shock vulnerabilities detected. I will update the agent procedures to detect the latest version of these, however the most reliable detection method remains checking the bash version details against the latest bash patch known to have these issues fixed.
Please see en.wikipedia.org/.../Shellshock_%28software_bug%29 for a description of these additional vulnerabilities.