We've been getting an increasing number of questions about the ShellShock vulnerability that was announced, this post will collect the status across different products into one place to make it easy for you to determine if your product is affected or not.
What is ShellShock? How does it work?
ShellShock is a vulnerability in a command shell commonly used on Linux (and some other Unix flavors) - basically EVERY Linux system out there (before yesterday that hasn't been patched today) is vulnerable in some fashion. The vulnerability allows someone with local access to log in to a Linux system OR remotely run unchecked commands to a linux system (via the web, for example) to elevate their privileges such that they may even have root-level access (at least, they'll have the context of the process they exploited - the service or user account). At that point, changes could be made to the system, additional services could be run (to do things like serve exploit or phishing sites), and further exploits could be attempted to get root-level access and full control.
There is not YET a massive scale exploit of this vulnerability, but it's entirely possible that before the day is done, one will be in the wild (we're already seeing smaller scale exploits winding up). With so many web applications that control and access Linux systems (doing things as simple as image manipulation or as complex as system management control panels, for example) and the common usage of Linux for web servers and application platforms in general, it's probably not going to be very long before something is written and scaled to take advantage of this exploit and create a ton of zombie systems out there.
For more reading, there's a great summary post here: Troy Hunt: Everything you need to know about the Shellshock Bash bug
What SolarWinds Products are Affected?
First, anything that exists exclusively on Windows is not affected. This is the majority of SolarWinds products - including NPM, SAM, NCM, Patch Manager, and more.
Products installed on a Linux OS or used to manage a Linux OS are not vulnerable, but their underlying system may be. Storage Manager or Serv-U on Linux isn't affected, but if your Linux OS is, you should consider that system at-risk. Similarly, if you are using LEM agents or monitoring Linux systems, those software bits are okay, but the underlying OS probably isn't.
The only affected products are our virtual appliance-based products, which run limited versions of Linux.
Below is a chart of all products, which are affected, and mitigation or resolution steps you can take if necessary.
| Product | Affected? | Notes & Next Steps |
|---|---|---|
| Alert Central | Partially, See Notes | Alert Central is running a vulnerable version of bash, however at this point none of the exploit vectors apply:
To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure. To be safe, we will include the updated bash software in an upcoming Alert Central release. If it becomes necessary to issue a patch, we will do so. More info will be posted here. |
| Log & Event Manager (LEM) | Partially, See Notes | LEM is running a vulnerable version of bash, however at this point none of the exploit vectors apply:
If you are still concerned, you should limit access to the virtual appliance management console and restrict SSH access to LEM using the LEM advanced configuration console (CMC).
To be safe, we will include the updated bash software in an upcoming LEM release. If it becomes necessary to issue a patch, we will do so. More info will be posted here. |
| Virtualization Manager | Partially, See Notes | Virtualization manager is running a vulnerable version of bash, however at this point none of the exploit vectors apply:
To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure. To be safe, we will include the updated bash software in an upcoming Virtualization Manager release. If it becomes necessary to issue a patch, we will do so. More info will be posted here. |
| Web Helpdesk (WHD) | Partially, See Notes | Web Helpdesk is running a vulnerable version of bash, however at this point none of the exploit vectors apply:
To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure. Please also note this KB article for WHD Virtual Appliance patch SolarWinds Knowledge Base :: Bash Code Injection Vulnerability - Shellshock. To be safe, we will include the updated bash software in an upcoming WHD release. If it becomes necessary to issue a patch, we will do so. More info will be posted here. |
| Patch Manager | No | |
| DameWare | No | |
| Firewall Security Manager (FSM) | No | |
| Storage Manager | No | When the patch is installed on the same system, Storage Manager will continue to function normally. |
| Serv-U Products | No | Serv-U does not run any shell scripts except during install time and it sets no environment variables. The only other use of sub process spawning is direct shell commands to manipulate files, and no environment variables are set. |
| Network Configuration Manager (NCM) | No | |
| Kiwi Products | No | |
| Enterprise Operations Console (EOC) | No | |
| Web Performance Monitor (WPM) | No | |
| Server & Application Monitor (SAM) | No | |
| Network Performance Monitor (NPM) | No | |
| User Device Tracker (UDT) | No | |
| Network Topology Mapper (NTM) | No | |
| Netflow Traffic Analyzer (NTA) | No | |
| Failover Engine (FoE) | No | |
| Mobile Admin | No | |
| ipMonitor | No | |
| IP Address Manager (IPAM) | No | |
| VoIP and Network Quality Manager (VNQM) | No | |
| Free Tools | No | |
| Database Performance Analyzer (DPA) | No | |
| Engineers Toolset | No |
Can any SolarWinds products help determine if I have other systems affected?
If you've got Server & Application Monitor, user mcam posted a template you can use here in our Content Exchange: Bash Vulnerability Test. You can use this to check and change the status of a monitored Linux node if it comes up vulnerable.
How do I fix them or prevent them from being attacked?
The fix is pretty straightforward - check your Linux distribution maintainer for an update to bash, or as Troy Hunt suggested in his article, compile and deploy your own.
You can prioritize what to fix based on how the attack works (requires a shell to be ran to instantiate the attack):
- Systems with web or remote control applications that run local commands on the appliance after taking input from users
- If you can identify a known vulnerable application (e.g. cPanel), patch the application AND the system - there may be future attacks that the application will now also protect you from
- Systems with accounts where you allow people to log in and run commands arbitrarily
- Systems with sensitive data or access to sensitive networks
- Anything else!
If you can't fix something right away, here are some suggested mitigation steps:
- Disable or limit access to web or remote control applications that run local commands - ESPECIALLY from the public-facing internet.
- NOTE: If you're using SSH, it can't be exploited EXCEPT by an authenticated user, so you don't necessarily need to limit visibility entirely (though it may still be a good idea!)
- Disable or limit access (local or remote) from any unnecessary accounts.
- For accounts that run services, prevent them from logging in and spawning a shell.
- NOTE: Make sure any services you're running, especially accessible from the internet, use service accounts, not root.
- For accounts that only need access to something like FTP, prevent them from logging in and spawning a shell.
- Audit for dead accounts - users that may not exist any longer.
- For accounts that run services, prevent them from logging in and spawning a shell.
- Consider disabling login access to systems that have access to sensitive data or networks to only critical users while you deploy the fix.
- Monitor for common post-attack signs:
- Usage of the root account
- Services restarting (could be a sign of configuration changes)
- Accounts being created and/or sudo access being granted
- Monitoring systems being disabled/shut off
We'll update this post if anything changes or as more information becomes available on the updates for our virtual appliances.