If you work with Windows and Unix/Linux platforms, no doubt you are familiar with PuTTY, one of the more ubiquitous tools found on many administrator and developer workstations. Microsoft Windows lacked an SSH client until fairly recently, and previously, if you wanted to connect to any Unix system from a Windows machine, you would need an SSH client. PuTTY, by developer Simon Tatham, is a popular, versatile, open-source terminal emulator, serial console and file transfer application.
Like all software, PuTTY is complex, and complex things can have flaws. Sometimes, those flaws can be leveraged by a malicious actor. Back in March 2019, PuTTY received updates, fixing eight vulnerabilities and LibSSH2, a companion library for SSHv2, received fixes for nine vulnerabilities.
These vulnerabilities represent a number of different scenarios. Some allow possible DoS attacks; others, the leaking of the private key phrase; and yet others, the possibility of executing arbitrary code on the vulnerable system. Considering that the people who may need to connect to remote systems (typically servers) via SSH will be administrators or users with elevated access—and they comprise the main user group of PuTTY—we can see there is risk involved in not mitigating these vulnerabilities as quickly as possible.
Addressing your challenges
So, picture this scene: You and your colleagues run and manage close to 100,000 endpoints across your global organization. These include servers, workstations, laptops, VMs, cloud instances running on premise, on the road, in your cloud or in someone else’s cloud, all with a range of operating systems, applications, application owners and stakeholders. At a minimum, these are your challenges:
- How quickly could you find all instances of PuTTY or associated applications and ensure that they were up-to-date?
- How can you make sure that, as admins and developers come online as the working days starts around your global offices, any issues are automatically remediated?
- How can you be sure you are organizationally up-to-date when your CIO or CISO asks for a status after seeing the latest news about whatever major security incident is making headlines that morning?
Those tricky challenges are where Tanium can uniquely help. To prepare, consider the following, again using PuTTY as an example:
- Are we vulnerable?
How can we ensure there are no outdated versions of PuTTY or LibSSH2 anywhere in our organisation? How can we report on this in real-time and be sure of the results?
- Is anyone trying to use these vulnerabilities to gain access? We want to specifically look for any behavioural indicators that might suggest malicious activity around the vulnerabilities that would necessitate further investigation.
- How can we make sure everyone has access to the updated version? Can we push the updated version of PuTTY and associated tools out to our Admin groups, or at least allow people to install this as part of application delivery self-service?
- Can we both detect and prevent the use of vulnerable versions of the software?
Let’s look at each of these sections and what Tanium can provide.
1. Real-time view
First, we could obtain a real-time view of all PuTTY installs across our estate.
We would ask the Tanium question: “Get Installed Application Version[putty] < 0.71.0.0 from all machines with Operating System contains windows”
Or we could ask for all of the installed applications and filter with the word “putty”, selecting to represent the live results in a handy chart format:
Tanium Index is a component of our Threat Response module, and a critical enabler to security use cases involving detection and reporting of threat indicators for files at rest. We can use this module to do a search—in real-time—across all our managed systems for the existence of any version of putty.exe. This is important, as in many cases, PuTTY will not actually be an installed application, but exist on an endpoint as a standalone executable. How can we be sure we can find it in every circumstance?
Trace Event Recorder is another component of our Threat Response module. We can use Trace to directly investigate key forensic and security events on Linux, Mac and Windows endpoints across a network. Trace provides a live and historical view of critical events including process execution, logon history, network connections and file and registry changes. For our example, we want to know if anyone has executed PuTTY anywhere across our managed systems in the last 30 days. In the example below, we can see that a user “Elain_Devito” has done exactly this.
Next we might want to try to see if there has been any suspicious behaviour which could reflect a bad actor trying to leverage one of the PuTTY vulnerabilities. With Tanium signals you can detect suspicious or interesting process behavior by combining multiple search expressions.
Below we have an example signal to detect activity that might be associated with one of the CVEs. Essentially, if any PuTTY related process spawns a command shell or PowerShell instance, then we want to know about it and be able to investigate.
3. Deploy package
Another opportunity to mitigate any risk from outdated versions of PuTTY would be to ensure we have an up-to-date package ready to push for installation to those administrator or developer users that need it. Here’s an example from our Deploy module:
In the following screenshot, we can see that PuTTY has been made available as a selectable option for the end-users in our Self Service application delivery portal where users can choose the packages they want to install.
4. Manage native security features using the Protect module
Here is yet another example of how Tanium’s speed and flexibility can uniquely help in this situation. You could prevent any vulnerable putty.exe executable being launched using an enterprise-level policy for AppLocker, using the “Protect” module with a pop-up on the endpoint alerting the user to upgrade via their Tanium self-service.
This seemingly simple scenario is repeated over and over, week by week, across countless organizations across the world. Existing operations and security tools are simply not fit for action at any real scale and typical answers from Security and Operations teams when asked “how long will this take” will range from “I’m not sure, “maybe a week?” to “We’re not able to do that with any certainty.’’
Your ability to respond to simple, typical events such as this must include the capability to react with agility and roll with the inevitable punches—at scale, with speed.