Three Types of Client-side Exploits

We often hear about vulnerabilities in client software, such as web browsers and email applications, that can be exploited by malicious content. The repeated stories about botnets, infected web sites, and viruses which infect us with malicious documents, movies, and other content have ingrained the concept of an exploitable client in our minds. Unfortunately, client software can also be targeted with attacks from compromised servers accessed by the clients, and some client software actually listens for connections. In this blog entry, we will discuss auditing client software for vulnerabilities and describe the three different types of client-side exploits and how they can impact the risk of your network.

Auditing Client-Side Exploits

The largest misconception I’ve encountered from security auditors who test client-side software is a focus on the operating system or application. Regardless of what scanner or patch management agent is in use, the administrators of such systems only test for items from the operating system manufacturer, such as only looking at Microsoft OS vulnerabilities. Nessus audits hundreds of different manufacturer patches and will readily identify issues in an operating system that were not shipped with the operating system. Major client-side security issues occur in well-known brands, such as Adobe, Firefox, and Apple, but also lesser known and less expected sources, such as McAfee, Symantec, and open source security tools such as Secure Shell.

The solution is to perform a complete patch audit of a scanned system. Nessus has the ability to detect thousands of client-side vulnerabilities in software installed from sources other than the base operating system. In lieu of performing a full patch audit, passive network monitoring with the Passive Vulnerability Scanner will identify client vulnerabilities based on DNS lookups, web queries, dedicated client protocols, and analysis of unencrypted conversations over FTP, SMTP, IMAP, SMB, and many others.

Type 1 - Traditional Client-side Exploits

There has been a lot of coverage of client-side exploits being used to create botnets and target specific organizations via a combination of social engineering and content with malicious payloads. These exploits target browsers, browser plugins, and email clients. Today, there is a fine line between email and web applications since many email applications share libraries when viewing emails that have been formatted with HTML content. We won’t spend any more time on this type of client-side exploit since this is the most commonly known type.

Type 2 – Clients with Exposed Services

Many types of client software will actually open up a socket and run a service that communicates on the network. From the perspective of a penetration tester or a vulnerability scanner, it really doesn’t make any difference if a piece of software is acting as a client for a user or if it is focused on serving data. If it has a socket open on the network and connections can be made to it, it may be exploitable. If the host is directly connected to the Internet or to mobile broadband networks and it does not have a firewall, it may be attacked directly without any need for user interaction such as opening an email.

When a Nessus vulnerability scan is configured without credentials, by default, Nessus will conduct scans for all vulnerable services, be they from traditional servers or services opened by client software. Within Nessus 5, this can be refined further within your scan policy by adding a filter for a “plugin type” of “remote” as compared to a credentialed “local” check. Combinations can be further added to target specific classes of software. For example, in the screen shot below, I created a filter to select plugins that identify vulnerable iTunes software with remote Nessus checks.

Type 3 – Clients Exposed to Hostile Servers

This type of client exploit may seem very similar to our first type, but the differentiation is that the server isn’t hosting hostile data –- the server itself can be manipulated to attack a client directly.

A classic example is CVE-2005-0467, which identifies a vulnerability in the PuTTY SSH and SCP clients that can be exploited by a malicious SSH server to execute code on connecting host. An example Nessus plugin that detects this is the credentialed Gentoo local check plugin.

Vulnerabilities like this can be used to hop through firewalls in a much more direct manner than by attempting to compromise an administrator’s system with some sort of Internet-based social engineering exploit. For example, let’s say you have a host in a DMZ which can be compromised from the Internet or Intranet, yet all administration to this system is performed through a one-way firewall. If the administrative access to the DMZ systems is allowed from an internal network and there is vulnerable client software in use, a DMZ server under control of an attacker could modify the service to conduct attacks against the client.

I’ve highlighted some example vulnerabilities detected by Nessus that could be used to run code from a maliciously controlled server:

Code execution in FTP clients:
21565 FileZilla FTP Client Unspecified Overflow

Code execution in SSH clients:
37021 FreeBSD : putty -- buffer overflow vulnerability in ssh2 support (19518d22-2d05-11d9-8943-0050fc56d258)

Code execution in SNMP clients:
38099 USN-685-1 : net-snmp vulnerabilities

Code execution in web clients:
49102 USN-982-1 : wget vulnerability
45133 Firefox < 3.6.2 Multiple Vulnerabilities
51162 MS10-090: Cumulative Security Update for Internet Explorer (2416400)

Tenable customers who use the Passive Vulnerability Scanner and SecurityCenter can leverage the trust relationships found through network analysis in order to identify all of the client IP addresses from which a server might accept connections. For example, in the screen shot below, I’ve added a view of a SecurityCenter Detailed Vulnerability Report about a trust relationship between 192.168.1.13 and 192.168.1.16 on port 22.

In this case, 192.168.1.16 is the server and has been observed to receive connections from 192.168.1.13 on port 22. This information is useful to SecurityCenter users because it can be used to create a dynamic asset list of all clients that access 192.168.1.16. This information is called a Dynamic Asset List. Lists such as this can be used within SecurityCenter to create dashboards, alerts, and reports about any type of security issues with clients that have access to sensitive servers.

Conclusion

The three types of client-side exploits described here can be detected with credentialed Nessus auditing, some uncredentialed Nessus scans, and by monitoring traffic in real time with the Passive Vulnerability Scanner. If you can’t patch all of your client vulnerabilities in a timely manner and have to perform a risk analysis in order to prioritize, knowing how the client software is used and what type of exploits it may be exposed to can help you rank which issues you need to mitigate first.